Each AI agent should authenticate as itself, with its own identity and short-lived credentials scoped to the task in hand. The governing layer holds those credentials and presents them only after an action has been allowed, so the model never sees a secret. Shared service accounts and borrowed human logins make every action unattributable and should be retired.
Why does each agent need its own identity?
Because every action has to be attributable. If three agents and two scripts use one service account, the system of record shows that "svc-integration" changed a customer's address. It cannot show which agent did it, under which certificate, or on whose request. An auditor reading that log learns nothing useful.
A distinct identity per agent fixes that and enables the rest: you can revoke one agent without breaking others, limit each to the systems its role needs, and see in your systems' own logs which agent acted.
Borrowed human credentials are worse. An agent logged in as a staff member inherits all of that person's access, which is almost always more than the agent's role needs, and its actions look like the person's.
How does authentication work in practice?
The common pattern has four parts.
- The agent has a workload identity issued by your identity provider, like any other service.
- The governing layer requests a credential for a specific action, scoped to the systems and operations that action needs, and short-lived.
- The call is made by the platform's connector, presenting the credential to the target system. The model proposes the action; it does not hold the token.
- The target system checks the credential as it would for any client and applies its own access rules.
Where an agent acts for a specific customer or employee, the credential can carry that delegation, so the target system knows both who is acting and on whose behalf.
Keeping credentials out of the model's context matters for a specific reason: an injected instruction cannot exfiltrate a secret the model never saw. More on connection design is in how to connect an AI agent to your systems.
What may the agent do, and what stays with a person?
| Activity | Agent or platform | Person |
|---|---|---|
| Hold its own identity | Platform holds it for the agent | Identity team issues and revokes it |
| Request a credential for an allowed action | Platform, after the verdict | None |
| Gain access to a new system | Never on its own | System owner approves the connection |
| Widen a credential's scope | Never | Approved as a change to the agent's role |
| Use a person's login | Never | Not permitted |
The pattern is that agents use access, and people grant it.
What does this look like in practice?
Take a finance team's agent that reconciles records between two systems: the bank feed and the general ledger. Its role is to match transactions and post clearing entries to a suspense account.
It has its own identity. For each matching run, the platform obtains a read-only credential for the bank feed and a credential for the ledger that permits posting only to the suspense account. Both expire within the hour. When the agent proposes a clearing entry, the platform checks the agent's bounds, then makes the call with the ledger credential. The ledger's own log shows the agent's identity against each entry.
When the agent proposes a correcting entry to a revenue account, the ledger credential cannot do it, and the platform refuses before trying because the role does not include that capability. Two independent checks, one outcome.
What controls make agent authentication safe?
- One identity per agent, never shared between agents or with scripts.
- Short-lived, narrowly scoped credentials issued per action or per task.
- Secrets held by the platform and never placed in the model's context.
- Revocation that takes effect immediately, and is tested.
- Systems that cannot support per-agent identity sit behind a gateway that adds it.
Agent authentication does not replace the systems' own access control. An agentic operating system adds to them, as explained in whether it replaces your existing systems. The full design is in the governed agentic operating system guide.
Where Pryme fits
In Pryme, each agent acts under its own identity and every action passes the minimum chain before any credential is used: role scope, certificate, sources, your limits and the platform guardrails. The verdict, including which bound decided, is filed alongside the identity that acted.
Questions people ask
Can an agent use an API key?
It can, but long-lived keys are risky. If you must use one, keep it in the platform's vault, scope it narrowly, rotate it and never put it in a prompt or tool description.
What about legacy systems that only support shared accounts?
Put a gateway in front that authenticates each agent separately and records which agent made each call. The legacy system still sees one account, but your record does not.
Should agents authenticate to each other?
Yes. A request from one agent to another should be signed by the sender's identity, so the receiver and the record know exactly who asked.