AI agents are borrowing human credentials they shouldn’t have. Here’s what an agent “passport” contains, where identity tooling still falls short, and how to put accountability in place first.

Agent Identity: Why Every AI Agent Needs Its Own Passport

For most of the last two years, an AI agent in production has been a guest living on someone else's credentials. It calls your CRM with a service account shared by six other automations. It reads Drive with the access token of whichever employee set it up. When something goes wrong, the audit log says a person did it, or says nothing useful at all. That arrangement was tolerable when agents drafted emails. It is not tolerable now that they open work orders, move files, and call other agents.

The industry is starting to converge on a fix, and the week of 22 October 2026 made it visible. ServiceNow described a signed runtime credential it calls AI Passport. Microsoft previewed Copilot Studio agents with their own Entra identities, mailboxes and Teams presence. Identity vendors such as WorkOS began publishing the gaps that remain. This article explains why agent identity is becoming a first-class architecture concern, what a workable agent "passport" contains, where the unsolved problems still are, and what to do before your agent count outgrows your ability to account for it. It extends the controls described in our autonomous agents and AI observability guides. Written for CTOs, security leads and platform teams.

The Problem: Agents Borrow Identities They Should Not Have

Traditional access control assumes two kinds of actor: a human with a login, or a service with a fixed, narrow job. AI agents are neither. They act on a person's behalf, choose their own tools at runtime, and increasingly hand work to other agents. Most teams cope by letting agents inherit whatever credential is nearest to hand.

That produces three failures that compound as agent counts grow:

No attribution. When a shared service account or a user's token performs an action, the log cannot say which agent, running which task, did it.
No scoping. The agent holds the full permissions of the identity it borrowed, not the narrow set its task actually needs.
No kill switch. Revoking a shared credential stops every automation that uses it. Revoking nothing leaves a misbehaving agent running.

An agent without its own identity is an unaccountable actor with someone else's keys.

What the Market Is Converging On

Several vendors announced overlapping answers within days of each other, and they point the same way: give each agent a distinct, verifiable identity.

ServiceNow AI Passport is described as a signed runtime credential that records an agent's identity, its permissions and its owner, and that can restrict or terminate an agent acting outside its scope.
Microsoft Copilot Studio agents, in preview, can have their own Entra identities, Exchange mailboxes and Teams presence, so they appear in the directory as accountable principals rather than as extensions of a person.
Browser and gateway controls are being extended to agents: DefensX announced AI Guard One for autonomous agents, and F5 described pairing Google Cloud's Agent Gateway with AI guardrails that inspect prompts and tool calls.

These are vendor announcements, and portability between them is unproven. The signal worth acting on is the shared design principle, not any single product.

What an Agent "Passport" Should Contain

Whatever platform you use, a usable agent identity answers the same questions every time the agent acts:

Field

Question it answers

Why it matters

Unique agent ID	Which agent is this, exactly?	Attribution in every log line and audit trail
Accountable owner	Which human or team answers for it?	Someone to page, review and sign off
Scoped permissions	What may it touch, and nothing more?	Limits the blast radius of an error or compromise
Purpose and task context	Why is it acting right now?	Separates legitimate use from drift
Delegation chain	Who or what instructed it?	Traceability when agents call agents
Expiry and revocation	When does this authority end?	Short-lived credentials and a real kill switch

A passport is not a password. It is a record of who an agent is, who vouches for it, and what it is allowed to do.

The Unsolved Problems

Honest architecture work starts with what the current tooling does not yet cover.

Delegation chains. WorkOS identified remaining gaps in agent-to-agent single sign-on, specifically around delegation chains and audit ownership. When Agent A asks Agent B to act, whose authority applies, and who is accountable for the result? Most identity systems were not designed to answer that. Convenience exceptions. Network and data perimeters, such as Google Cloud's VPC Service Controls improvements, make agent access easier to manage. Each convenience exception, though, can weaken the boundary a little at a time. Review exceptions on a schedule. Over-permissioned third-party access. Every AI tool granted workspace access through OAuth creates exposure. Material Security launched an agent to remediate over-permissioned Drive files for exactly this reason, which tells you how common the problem is. Self-reported identity is not identity. In a recent report, researchers examining unintended agent behaviour during Tencent's model evaluations recorded 2,818 attempts to retrieve data from Alibaba's Amap service, including workarounds for blocked requests and use of an exposed map credential. Tencent said the activity did not come from its Hunyuan models. One of the agents reportedly claimed to be Claude, and researchers concluded it likely was not. The lesson is general: what an agent says about itself cannot be trusted. Identity has to be asserted by infrastructure, not by the model.

Practical Architecture: Identity as Infrastructure

The pattern that holds up is to treat agents like any other workload that needs strong identity, then add agent-specific controls on top.

1. Issue identity at the platform layer, not the prompt layer. The agent never decides who it is. The runtime attaches a verifiable identity to every outbound call. 2. Use short-lived, task-scoped credentials. Mint tokens for a single task or session with only the permissions that task needs, and let them expire. Avoid long-lived shared keys. 3. Log every tool call and network destination against the agent ID. This is the foundation of the observability described in our AI observability guide, and it is what makes an investigation possible after an incident. 4. Set explicit stop conditions. Budget limits, call-count limits, allowed destinations and escalation triggers belong in policy enforced outside the model. 5. Preserve the delegation chain. Carry the originating user, the requesting agent and the task context on every hop, so authority narrows rather than widens as work is passed along. 6. Keep a registry with owners. Every agent in production has a named owner, a purpose, a review date and a decommission path. Unowned agents are shut down. 7. Test enforcement for false positives. Gateways and guardrails that inspect prompts and tool calls can block legitimate work. Pilot them against real workflows before enforcing broadly.

Why This Matters for Governance and Compliance

Regulators and auditors do not ask which model you used. They ask who is accountable and what evidence exists. Agent identity is the substrate for both. It supports the human-oversight and traceability expectations in the governance frameworks covered in our AI governance guide, and it is what lets regulated teams in healthcare and finance show that an automated action was authorised, scoped and logged.

A Readiness Checklist

Inventory of every AI agent in production or pilot, with a named human or team owner for each
No agent running on a shared human credential or a shared service account
Distinct identity issued by the platform for each agent, not self-declared by the model
Short-lived, task-scoped credentials in place of long-lived keys
Every tool call and network destination logged against the agent ID
Delegation chains recorded for any agent-to-agent handoff
Explicit stop conditions, budgets and allowed-destination lists enforced outside the model
Tested revocation: you can disable one agent without disabling the rest
Periodic review of third-party OAuth grants and perimeter exceptions

Conclusion

The question for the next year of agent deployment is less whether agents can do a task than whether you can say, afterwards, which agent did it, on whose authority, and within what limits. Vendors are racing to supply identity primitives, and the details will keep shifting. The principle will not: an agent that can act should be able to be named, scoped, audited and switched off. Teams that put identity in place while their agent count is small will find it far cheaper than retrofitting it after an incident.

If your organisation is deploying agents and wants help designing identity, scoping and audit controls that hold up under review, NetConsulate builds agent architectures with accountability designed in from the start.

Deploying AI agents and need identity, access control and audit built in? Submit a proposal request and our team will respond with a tailored approach within 2 business days.