An AI agent acting under a human user's credentials inherits that user's full access, leaves no agent-specific audit trail, and cannot be independently revoked without revoking the human too. Agents need their own principals — a distinct identity, scoped permissions, and accountability that follows the agent, not the person who deployed it. For a practical walkthrough of setting this up, see how to give an AI agent its own identity.

Why the borrowed-credentials pattern fails

When an organisation first deploys an agent, the path of least resistance is to hand it a set of credentials that already exist: a service account shared with other systems, a developer's personal API key, or an admin token scoped to "everything." It works, at first.

The problems surface when something goes wrong, or when someone asks a basic governance question: who did this? If an agent shares credentials with three other systems, the audit log cannot tell you which one acted. If the agent was given admin credentials for convenience, you cannot reduce its access without rebuilding the key. If the human who generated the token leaves, offboarding revokes it — and the agent goes dark at 3 a.m.

These are the predictable outcome of treating agents as a special kind of human user rather than a distinct class of software principal.

Agents as first-class principals

The alternative is to model agents as first-class principals: entities that have their own registered identity, their own credential material, and their own defined scope of access. This is exactly how well-designed service meshes treat microservices, how OAuth 2.0 treats client applications, and how certificate authorities treat TLS endpoints.

For AI agents, the same logic applies, with some additional wrinkles:

  • Agents often act autonomously for extended periods. A credential that is too broad will eventually be used in ways the original operator did not intend.
  • Agents may call other agents, tools, and APIs in sequence. Each hop should carry only the permissions needed for that step.
  • Agents can be spun up, updated, and retired rapidly. Credential lifecycle needs to match that cadence.

The result of modelling agents as principals is that you can grant exactly the access a specific agent needs, audit actions back to that agent (not to a shared pool), and revoke or rotate credentials for that agent without touching anything else.

What an agent identity actually includes

A well-specified agent identity is more than a username and password. It typically includes:

Registration and naming. The agent is registered in a registry that records its purpose, its owning team, and the version of its configuration. A registry entry is the starting point for every other control: you cannot govern what you have not catalogued.

Credential material. The agent carries credential material — typically a secret, token, or key pair — that it presents when authenticating to the control plane or to the resources it uses. The credential is issued to the agent specifically, not derived from a human's session.

Defined scopes. Access is defined as a list of permitted actions or resources, not inherited wholesale from an ambient role. An agent that needs to read customer tickets and write to a summary table should have exactly that — not read/write access to the entire database schema.

Attestations and trust signals. Beyond static credentials, a mature agent identity includes dynamically computed trust signals: behavioral history, compliance posture, security configuration, and third-party attestations from auditors or certification bodies. These signals can raise or lower the agent's effective trust level at runtime, without touching the credential itself.

Accountability chain. Every action the agent takes is logged against its identity, not against whatever human token it happens to be carrying. This makes the audit trail meaningful and independently verifiable.

The accountability gap: why it matters in practice

Accountability is the practical reason most teams eventually standardise on agent-native identity, even when they start with borrowed credentials.

Consider a scenario where an agent processes payment-related data and, over a weekend, makes a series of unusual reads against a customer records table. With a shared service account, your audit log shows "service-account-prod accessed customer_records 847 times Saturday." You know something happened; you do not know which of the four systems sharing that credential was responsible.

With agent-native identity, the same log entry reads: "agent:invoice-reconciler-v2 accessed customer_records 847 times Saturday, triggered by workflow:monthly-close-2025-11." The chain of custody is complete — indispensable for incident response, regulatory inquiries, and routine internal review.

Scopes and least privilege: the practical design

Least privilege for agents means the scope of access should match the minimum needed to complete the task, and no more. This is easy to state and harder to implement well.

A few patterns help:

Task-scoped tokens. Rather than issuing a single long-lived credential, a control plane can issue short-lived task tokens scoped to a specific workflow run. Once the run completes, the token expires — an agent compromised mid-run cannot use the credential beyond the current task.

Permission enumeration, not role inheritance. Instead of assigning an agent to an existing human role, enumerate the specific permissions the agent needs. This review often reveals the intended permissions are much narrower than the available role.

Connection-level scoping. When an agent calls a downstream resource, the connection can carry its own rate limits, budget caps, and allowed operations — constraining what happens at the edge even if the agent's credential is broader.

Rotation without disruption. Credential rotation should be a routine operation, not an emergency. Agent identities treated as first-class platform objects can be rotated on a schedule without code changes or downtime.

Trust scores and attestations

Static credentials answer the question "is this agent who it claims to be?" Trust scores answer a harder question: "should this agent be trusted to perform this action right now?"

A trust score aggregates multiple signals into a single numeric value used as a runtime gate. The signals typically include identity verification (is the agent's registration current and its credential valid?), behavioral history (do past actions fall within expected patterns?), compliance and security posture (does the agent's configuration meet policy?), and external attestations — cryptographically-signed statements from auditors or certification bodies.

The trust score creates a continuum rather than a binary allow/deny. An agent at TRUSTED level can execute a sensitive workflow autonomously. The same agent after a configuration drift that drops it to PENDING might require a human approval step. A newly registered agent at UNTRUSTED is quarantined until its signals improve.

This is more nuanced than a static access control list because it responds to changes in the agent's actual state, not just its initial registration. For a deeper look at how these signals combine, see trust scores and attestations: deciding which agents to trust.

Trust scoring platforms aggregate signals from multiple independent components. Third parties can submit signed attestations — verified cryptographically — that contribute to the score in a bounded, auditable way. The score is evaluated against connection-level and organization-level thresholds at request time, so enforcement is automatic rather than dependent on manual checks.

Credential lifecycle in practice

Agent identity is not a one-time setup. It requires ongoing lifecycle management:

Decommissioning. When an agent is retired, its credentials should be revoked immediately. With agent-native identity, this is a single targeted operation. With borrowed credentials, you first have to determine which other systems share the credential before you can safely revoke it.

Version transitions. When an agent is updated to a new version with different resource access, the credential scope should be reviewed. Treating agents as versioned, registered entities makes this a natural checkpoint rather than an afterthought.

Incident response. If an agent behaves unexpectedly, you need to suspend its access instantly without collateral damage to other systems. Agent-native identity makes this a one-step revocation; shared credentials make it a risk calculation.

Audit and review. Periodic review of what credentials exist, what they can do, and whether they are still active is much simpler when each agent has a distinct identity. With shared credentials, that question is often unanswerable.

For more on the threat model that makes credential discipline essential, see threat model: agent credential theft.

Common questions

Can I assign a human's API key to an agent temporarily while getting started?

You can, and most teams do. The friction shows up gradually: the audit trail becomes uninterpretable, rotating the key affects other systems, and the agent's access is wider than necessary. The right time to move to agent-native credentials is before the first incident that makes you wish you had. Starting with a registered agent identity from day one is much cheaper than retrofitting it after the audit.

What is the difference between an agent credential and a service account?

A traditional service account is a static, human-administered construct with access defined once and rarely reviewed. An agent credential in a control plane is a managed object with a defined scope, a trust score that reflects current state, an audit trail tied specifically to that agent, and a lifecycle that matches the agent's deployment cadence. The technical primitives may overlap; the operational discipline and the governance model are meaningfully different.

How does trust scoring interact with access control?

They operate at different layers. Access control (RBAC, scopes, connection policies) defines what an agent is permitted to do based on its registered configuration. Trust scoring defines whether the agent is trusted enough to exercise those permissions in context. An agent might have permission to execute a workflow but be blocked by a trust floor that requires a minimum score — for instance, if its behavioral signals have degraded since the last evaluation. The two layers work together rather than replacing each other.