Building Continuous Trust: A Developer's Guide to Agent Identity Verification
Most identity systems were built to answer one question, once: is this the right person, at login? Agentic AI breaks that assumption. An agent can be legitimate at the start of a session and compromised three steps later, and nothing in a traditional auth flow is designed to notice the difference.
Solving this isn't one fix. It's a trust layer cake, where each layer handles a different part of the problem, and none of them alone is sufficient.
Layer 1: Credential Issuance, Scoped and Short-Lived
The bottom layer is what the agent holds in its hand when it acts. A static API key granted once at setup is the equivalent of a password that never expires: if it leaks, or the agent is manipulated into misusing it, the blast radius is everything that key can touch, indefinitely.
The fix at this layer: task-scoped, short-lived tokens, issued per action rather than per session. Stripe's recent approach to agent payments is a clean real-world example: instead of exposing a real card to an agent, it issues a one-time-use card or Shared Payment Token per transaction, so the agent never gets access to the raw payment credentials, and a compromised agent can misuse at most one scoped payment, not the account [1]. The same pattern generalizes beyond payments: narrow the token to exactly the action being taken, and let it expire the moment that action completes.
Layer 2: Context and Tool Access, and Where MCP Stops
Model Context Protocol has become the standard way agents connect to tools and data. It's worth being precise about what MCP does and doesn't solve. MCP is an open protocol that standardizes how an LLM application requests context and calls tools across data sources, it's a communication layer, not a permission system [2]. It doesn't, by itself, verify that the agent calling the tool is still the agent the user authorized, or that this specific call is within scope.
That verification has to be layered on top of MCP, not assumed from it. In practice, that means every MCP tool call should be evaluated against the scoped credential from Layer 1 before execution, not after. The protocol carries the request; it shouldn't be trusted to also carry the authorization.
Layer 3: Behavioral Verification, Continuous and Not One-Time
NIST's AI Risk Management Framework frames this precisely: AI systems operate across a spectrum of autonomy, and governance needs to account for where a system sits on that spectrum at any given moment, not just at deployment [3]. Translated into architecture, that means re-evaluating risk signals on every significant action, not once at session start: does this action match the agent's normal pattern, is it within the task the user actually requested, does the sequence of calls make sense together.
This layer runs in the background, the same way a bank's fraud engine scores a transaction without interrupting checkout. It's the layer that catches an agent that's still holding a valid token but has started doing something it wasn't asked to do.
Layer 4: Audit, Tying Every Action Back to Its Authorization
The top layer is the one most systems skip until after an incident: a clear, queryable record connecting every action an agent took to the specific authorization that permitted it. Not just “the agent did X,” but “the agent did X, using credential Y, issued for task Z, requested by user W, at time T.” Without this layer, the first three don't help you investigate anything after the fact, they only help you prevent it in the moment.
Stanford's Digital Economy Lab, through its Loyal Agents initiative, is developing exactly this kind of framework: authenticated, authorized, and auditable delegation of authority to AI agents, letting a human restrict an agent's scope while preserving a clear chain of accountability [4].
What this looks like stacked together
None of these four layers is exotic on its own. Scoped tokens, protocol-level context passing, behavioral scoring, and audit logging all exist today as individual primitives. What's missing in most agentic systems isn't the technology, it's the assumption that authentication is a one-time gate at the bottom of the stack, instead of a property that has to hold at every layer, on every action, continuously.
References
[1] Stripe, “Giving agents the ability to pay” (2026). https://stripe.com/blog/giving-agents-the-ability-to-pay
[2] Model Context Protocol, official documentation.
[3] NIST, AI Risk Management Framework (AI RMF).
[4] Stanford Digital Economy Lab, “Authentication for AI Agents (Privacy and Security),” Loyal Agents Initiative. https://digitaleconomy.stanford.edu/project/loyal-agents/authentication-for-ai-agents-privacy-and-security/
About the Author
Karina Portugal works in enterprise identity and fraud prevention, currently as Director, Banking, Marketplaces, Strategic Partnerships & Agentic Trust at Prove, where she works closely with engineering and product teams on trust infrastructure for agentic systems across banking, marketplaces, and strategic partnerships. She writes on identity architecture, authentication, and the technical foundations of trust in agentic AI, and has completed executive programs at Wharton and Stanford focused on AI and emerging technology.
Comments
Loading comments…