Agent identity is the distinct, traceable identity assigned to an autonomous AI agent for authentication, authorization, and audit, separate from the human user or service account that may have initiated it. It covers the agent's identifier, who authored or deployed it, the credential type it presents, and the scope those credentials carry downstream.
- A distinct, traceable identity for an agent, separate from its initiator
- Records the agent, its author, its credential type, and its downstream scope
- Credential scope can be user-scoped, maker-scoped, or service-scoped
- Audit regimes assume the actor in the log acted – agents break that
Why is agent identity important?
Agent identity matters because traditional identity systems were built for human users, and agents inherit those models and break them. Without a distinct identity, a security team cannot answer the questions governance actually turns on: which agent took this action, who authored it, what credential type did it use, and was that credential user-scoped or service-scoped.
The compliance consequence is concrete. Audit chains and regimes built around traceable accountability – SOX, HIPAA, PCI DSS – assume the actor named in the log is the actor that took the action. An agent authenticating with a human's credential satisfies the log format while breaking the assumption underneath it. The record says a person did something a system did.
Agent-to-agent composition makes this fragile rather than merely imprecise. Once one agent invokes another and the second inherits the first's authority, the chain between the action and any accountable party depends entirely on whether identity was captured explicitly at each step.
What is agent identity?
Agent identity is the practice of treating an AI agent as a first-class principal, with credentials of its own and an audit trail attached to them. It has four components, and omitting any one of them leaves a governance question unanswerable.
The agent identifier distinguishes this agent from every other, including other instances of the same configuration. The author or maker identity records which human built or deployed it, which is what establishes accountability when the agent itself cannot be asked. The credential type records how the agent authenticates – user-scoped, borrowing a person's authority; maker-scoped, carrying the builder's authority; or service-scoped, holding its own. And the credential scope records what those credentials reach in downstream systems.
Credential type is the component most often missing and the most consequential. A user-scoped agent has exactly the access of whoever ran it, which is usually far more than the task needs. A maker-scoped agent carries its builder's access to everyone who later uses it, which is how a low-code agent quietly becomes a privilege escalation path.
Types of agent identity
Agent identities divide by whose authority the agent carries.
User-scoped identities authenticate as the person who invoked the agent. Attribution collapses into that person, and the agent inherits their full access regardless of what the task requires. This is the most common pattern in embedded and low-code agents.
Maker-scoped identities authenticate as the person who built the agent. Everyone who uses it operates with the builder's permissions, which is convenient to deploy and difficult to reason about, since the effective access of a user depends on who authored the tool rather than on their own entitlements.
Service-scoped identities give the agent its own principal with independently defined permissions. This is the model that supports attribution and scoping properly, and it requires deliberate provisioning.
Delegated identities represent an agent acting for a user with explicit, bounded delegation rather than wholesale inheritance. This is where standards work is heading and where least privilege for agents becomes tractable.
Agent identity & Onyx
Onyx is expanding agent identity collection beyond traditional service accounts. The first surface is Copilot Studio agents, where Onyx captures connector identities, the identity of the author, and credential scope – specifically whether an agent is user-scoped or maker-scoped. That distinction is what determines whose access the agent is actually exercising, and it is rarely visible from inside the platform hosting it. The capability is expanding to Salesforce Agentforce, Claude Code, and other agent platforms.
Every agent is then treated as a distinct identity separate from the user who initiated it, with Just-in-Time access evaluated at the request boundary rather than at role assignment. Agent identity and access governance covers both the collection and the enforcement.
