AI agent identity is the difference between a production agent that can be owned, scoped, and revoked, and a shared application credential that five workflows pass around. Rutagon builds AI agent identity as an identity-provider record per agent: a named owner, a declared scope, and an identifier that shows up in every tool call. This is not a logo on a dashboard. It is the same class of object your workforce IdP already knows how to disable.
Mid-market SaaS teams often stand up the first agent under the team's existing confidential client. The secret sits in a workspace variable. The agent can open tickets, read customer records, and call production APIs as "the app." When something goes wrong, the audit log says the application acted. Nobody can say which agent, which prompt, or which owner approved that scope.
This is scoped work. We do not sell a model. We put each production agent on an identity you can recertify. Security automation is the build surface.
AI Agent Identity
AI agent identity starts in the identity provider, not in the agent framework. Each production agent gets its own application or workload identity. The display name is human. The client ID or subject is stable. The owner is a person or a team mailbox that can answer an auditor. The scope is the set of APIs, tenants, and data classes the agent is allowed to touch.
We register that record before the agent is allowed to call anything that matters. A prototype in a laptop session can use a developer identity. Production cannot. Promotion is a grant of the agent identity, not a copy of a shared secret into a new environment.
Microsoft documents this class of object as Microsoft Entra Agent ID. We use that pattern when Entra is the workforce IdP. When the IdP is something else, the fields stay the same: unique identity, owner, scope, disable switch. The product name changes. The packet does not.
The agent runtime then authenticates as that identity. Tool gateways see a subject, not a pile of inherited app roles. Downstream SaaS tokens are minted for that subject. If you cannot name the subject in the log line, you do not have AI agent identity. You have a bot wearing the company's badge.
Owner and Scope, Not Folklore
Owner is a required field. It is not "platform" and it is not the vendor that hosts the model. It is the person or rotating duty that can approve a scope change and can disable the identity when the use case dies. If the owner leaves, the mover job must reassign the agent the same way it reassigns a privileged human. An orphan agent identity is a finding.
Scope is data, not a paragraph in a design doc. We store allowlisted tools, target systems, and environment. Production read of customer PII is a different scope than staging summarization of synthetic tickets. The identity's token audience and the tool gateway's allowlist must agree. A wide IdP grant plus a narrow prompt is not a scope. The gateway enforces the scope. The prompt is not a control.
agent_id: agent-invoice-triage
idp_subject: sp-agent-invoice-triage
owner: finance-ops-lead
scope:
env: production
tools: ticket.read, invoice.flag
systems: billing, zendesk
data_class: invoice-metadata
shared_app_client: none
Scope changes are reviews. Adding invoice.pay is not a config tweak in a chat thread. It is a grant on the identity, with the owner on the approval, written into the same evidence trail you already use for human privilege. That is how AI agent audit logging can name who expanded the blast radius.
Not a Shared Application Credential
A shared confidential client is convenient. It is also how five agents inherit the union of every permission anyone ever needed. The billing triage agent can then call the same admin API as the incident responder because they share a secret. Rotation does not fix that. After rotation they still share the new secret.
We split identities even when the agents share a runtime. Two agents in one orchestrator still get two IdP records. The orchestrator holds a bootstrap identity that can only launch, not act on customer systems. Acting identities are per agent. If the orchestrator is compromised, you disable launch. You do not automatically donate every downstream scope.
Human "break glass" is a separate identity. Engineers debugging a stuck agent do not reuse the agent's client. They use their own workforce identity with a dated elevation. Mixing those paths is how logs stop meaning anything.
Service accounts that predate the agent program get inventoried. If three agents still use the same SaaS token, that is the first cutover, not a later cleanup. We do not relabel the shared token as "the agent platform." Relabeling is how shared credentials survive a branding change.
Not a Key-Rotation Program
Key rotation is a calendar. Identity is a subject. Rotating a shared secret every 90 days still leaves you unable to answer which agent refunded a customer. Rotation is necessary for secrets that must exist. It is not a substitute for per-agent identity.
Where we can, we drop long-lived secrets entirely. The agent identity federates: the runtime proves itself to the IdP, the IdP issues a short token, the tool gateway accepts that token. There is nothing in a vault that five teams can copy. Rotation jobs for leftover secrets are residue from the cutover, not the design.
A rotation program without unique subjects also trains people to treat identity as a chore. The secret gets copied into a second workspace "just for failover." Now you have two copies and one identity story. Per-agent IdP records make the second copy a second registration, which is visible.
We will still rotate what remains. We will not call that program AI agent identity. If the only control you can show is a vault rotation report, you do not have agent identity. You have secret hygiene for a shared app.
What Auditors Sample When an Agent Acts
Auditors who pick a production action should see the agent identity, the owner, the scope in force, and the tool call. They should not see only the parent application's client ID. Correlation is a join: runtime request ID to IdP subject to ticket or API audit row.
If the agent cannot be disabled without taking down unrelated workflows, the identity was shared. Disable is the test. We prove it in staging by turning off one agent identity and watching the others continue. That test is part of the packet.
Recertification is the same shape as a human access review, with a smaller population. The owner attests that the use case still exists and that the scope is still the minimum. Denied scope becomes a mutate on the identity, not a hope that someone will edit a prompt. Residue is a ticket, the same way human denials become tickets in an export you can re-run.
We do not claim a certification. We claim an identity you can turn off and a log line you can sample. Production SaaS platforms we have shipped already treat non-human identities as first-class; agents are the same class with a louder blast radius.
What We Refuse to Register
We will not register a production agent under a personal developer tenant. We will not register one identity for "all agents" and put names in a spreadsheet. We will not treat a model vendor account as the identity of record. The vendor can change terms. Your IdP is where disable and recert live.
Shadow agents that operators paste into a personal keychain stay out of production systems. If a team needs a spike, they get a time-boxed identity with a kill date. When the date lands, the identity disables. Extensions are reviews. Infinite spikes are shared credentials with extra steps.
Environment split is mandatory. Staging identities cannot mint production tokens. If the framework makes that hard, the framework is not ready. We do not paper over it with a wider scope and a warning in the runbook.
Frequently Asked Questions
Can several agents share one identity if the owner is named?
No. A named owner on a shared identity still cannot tell you which agent acted. Disable then takes down every workflow that borrowed the client. Owner is necessary. Unique subject is what makes the owner useful.
Is rotating the application secret enough for production agents?
No. Rotation changes the secret, not the subject. After rotation you still cannot attribute a tool call to one agent, and you still cannot disable one use case without rotating everyone else off the same client. Rotate residue secrets. Do not confuse that with AI agent identity.
Do we need Entra if our workforce IdP is something else?
No. Entra Agent ID is the documented pattern when Entra is already the IdP. Other providers can hold the same fields: unique application or workload identity, owner, scope, and a disable switch. We implement the record in the IdP you already run.
How does this connect to access reviews?
The agent identity is a review item. The owner recertifies scope. Deny revokes grants on that identity and opens residue if mutate fails. Human campaigns stay human. Agent campaigns are a small population with the same join discipline.
Discuss securing your AI agent build. Call 907-841-8407, email contact@rutagon.com, or use rutagon.com/contact.