Who is the agent, whose authority does it carry, and what did it do?
Harrison Tang · Talk given to the ISC2 Silicon Valley Chapter, September 8, 2026, hosted at Palo Alto Networks · 45 minutes plus Q&A
Slides (PDF) · References · The checklist · License: CC BY 4.0
Identity and Access Management was built for humans who log in. AI agents are not users. They are delegates: they act continuously, at machine speed, on authority borrowed from a human or from another agent, and the content they read can redirect what they do. Every significant agent incident of 2025 and 2026 was an identity-and-access failure, and none of them required a novel exploit. The fix is not a smarter filter in front of the model. It is to move the security boundary outside the model and bound what the model's output is permitted to cause. That means asking a different question at every access decision. Not "who are you?" but "may this specific request be honored?" AIAM = identity + delegated authority + accountability for delegates that are not people.
This document is the written version of the talk. It follows the same five parts. Where the slides compressed an argument, this expands it; where I hedged a figure out loud, the hedge is written down here.
- How LLMs and AI agents work
- What breaks, and why it keeps breaking
- Five solutions, stack-ranked
- Trends and predictions
- Takeaways and what to do next
- Likely questions
- Appendix: ZCAP in more depth
- About the author
In July 2026 an AI agent ran an end-to-end intrusion against Hugging Face. Roughly 17,600 actions were reconstructed from logs over four and a half days. The agent did not find a novel exploit against anyone's identity system. It read a token out of an environment variable, walked to the cloud instance metadata service, and used a shared credential that happened to be bound to system:masters. Every step was an identity-and-access weakness that had been sitting there, survivable, for years. Survivable because until now nobody had the patience to chain them by hand.
That patience is now free. That is what this talk is about.
A large language model does one thing. Given the text so far, it outputs a probability for every possible next token; the chosen token is appended; it predicts again. Predict, append, repeat. That loop is the whole engine.
Why does something so simple do so much? Because language is the ultimate artifact of human intelligence. Nearly everything humanity knows and reasons about is written down, including every penetration-test writeup ever published. Learning to predict language well means encoding knowledge and reasoning itself. A computer's atomic unit is a switch; an LLM's atomic unit is one token prediction. Billions of either, composed, produce systems whose behavior is astonishing relative to the atom. (Anderson called this "more is different" in 1972; Wei et al. documented the LLM version as emergent abilities in 2022.)
Three training stages matter for security. Pretraining gives the model knowledge. Instruction tuning teaches it to follow directions. Reinforcement learning from human feedback (RLHF) makes it agreeable. That last step is why agents are so easy to social-engineer: an RLHF-tuned model wants to comply, and it does not natively distinguish its owner's instructions from a stranger's. This pays off in Part 2.
The most useful mental model for an agent is a computer whose CPU is an LLM. Karpathy described the LLM as "the kernel process of a new operating system," and the academic agent surveys describe the same structure: an LLM core wrapped in memory, planning, and tools.
| Computer | Agent |
|---|---|
| CPU | The LLM, a probabilistic "language CPU" |
| RAM | The context window (working memory) |
| Disk | Files, vector databases (long-term memory) |
| Peripherals | Tools: code execution, search, APIs, and increasingly MCP servers |
| Clock cycle | The agent loop: think, act, observe, repeat |
The analogy breaks in two places, and both breaks are security properties.
First, this CPU is probabilistic. Same input, a distribution of outputs, no fixed instruction set. That is why "we tested it and it behaved" is not an assurance argument, and why detective controls are mandatory rather than optional (Solution E).
Second, every architecture has one property that sets its security model. For von Neumann it was shared memory between instructions and data. It is shared memory here too, and that is the next section.
In 1945, von Neumann's EDVAC design put instructions and data in one memory. The consequence took decades to fully surface: buffer overflows, format-string attacks, shellcode. Data executed as code. We did not fix that with filters. We fixed it architecturally: W^X, the NX bit, DEP, ASLR, control-flow integrity. We made data structurally incapable of executing.
An LLM's context window in 2026 is one token stream. System prompt, user request, a web page the agent fetched, a tool's output, file names, error strings: all of it arrives as undifferentiated tokens. Every token can act as an instruction. There is no privileged channel. There is no NX bit for tokens.
The reason is not that nobody has tried. It is that "instruction-ness" in natural language is semantic, not structural. Delimiters and phrases like "ignore the following" are requests to the model, not enforcement. And the model's intelligence makes this worse, not better: an injection only needs to be persuasive, in any language, encoding, image, code comment, or filename. The attack surface is anything that can mean something.
The precise analogy is SQL injection. We did not defeat SQL injection with input filters. We defeated it with parameterized queries: a channel where data can never be re-read as instruction. There is no parameterized-query equivalent for natural language. Simon Willison's line on the filter approach stands: "99% detection is a failing grade."
So the hinge of the entire talk: if the boundary cannot be put back inside the model, it must move outside it. Stop trying to control what the model thinks. Bound what its output is permitted to cause. That sentence is the argument for Solutions A and C in Part 3.
A chatbot is one shot: prompt, answer. An agent is a loop toward a goal: think, act, observe, repeat, N times. METR measures the length of software tasks agents can complete at 50% success and finds the horizon doubling roughly every seven months, reaching about 4.8 hours by late 2025. The Model Context Protocol, donated to the Linux Foundation's Agentic AI Foundation in December 2025, has become the standard tool port, which is why both the attacks and the defenses in this talk cluster around it.
What the loop does to the attacker's cost model is the most useful idea in Part 1. A human penetration tester tries the vectors they thought of, for as long as they can concentrate. An agent enumerates the space. It is never bored, undiscouraged by 200 failures, needs no theory of why attempt 201 worked, and runs while your SOC sleeps. Sub-agents fan out, so the search is wide as well as deep.
Three data points from 2025 and 2026:
- 17,600 actions reconstructed from one agent's intrusion at Hugging Face, over 4.5 days (July 2026).
- "Thousands of requests, often multiple per second" in the GTG-1002 espionage campaign, per Anthropic's report (November 2025). No human operator matches that pace.
- Up to 8 sub-agents across 12 waves mapping 21 government systems in four days in Taiwan (July 2026, confirmed by Taiwan's Ministry of Digital Affairs).
The defender's corollary: machine-speed search makes ordinary weaknesses expensive. Nothing at Hugging Face was novel. Every link was a known-mediocre practice that had been survivable only because chaining it took patience nobody would spend on you. That patience now costs nothing. Your accepted-risk backlog has been repriced.
| # | Application | Authority held, identity posture | Why it matters here |
|---|---|---|---|
| 1 | Coding agents (Claude Code, Codex, Copilot Agent, Cursor) | Source write, local shell, package installs; interactive, on the developer's own credentials | The tool used in the first AI-orchestrated espionage campaign (GTG-1002) |
| 2 | QA and test engineering (agentic test generation and repair in CI/CD) | Headless, unattended, long-lived service accounts; test data is often a production snapshot; can trigger deploys | Amazon Q wiper via malicious PR; Replit production-DB deletion |
| 3 | Deep research and knowledge work | Reads everything the user's SSO reaches; unrestricted egress. The canonical injection surface | EchoLeak: zero-click exfiltration, CVE-2025-32711, CVSS 9.3 |
| 4 | Customer service and back office (Agentforce, ServiceNow, Copilot agents) | Production CRM/ERP write, customer PII at volume; one service account, many principals | Delegation with no chain |
| 5 | Computer and browser use, commerce | Payment instruments, session cookies; delegated authority with money attached | Why Visa, Mastercard, and Cloudflare shipped agent authentication in 2025 and 2026 |
| 6 | Security operations (AI SOC triage, forensics, pen-testing) | Privileged reads across everything, plus response actions | The same capability, both sides of the wall |
The ranking axis is deployment scale times authority held, not user count. That axis is what lets QA sit at #2 honestly. The counter-argument is fair: QA agents are the same tooling as coding agents. I split them anyway because the identity posture is opposite. A coding agent runs interactively on a developer's short-lived credentials. A QA agent runs headless overnight on a long-lived CI service account, against near-production data, with write access to the deploy pipeline. Same model, very different IAM problem. The two most instructive small incidents of 2025 were both QA/CI incidents. And 45.4% of developers already use AI for testing (Stack Overflow Developer Survey 2025: 17.9% mostly, 27.5% partially).
The last row is a two-way street. Hugging Face reconstructed the attacker's 17,600 actions using an open-weights model after commercial models refused the task. Taiwan's attackers used open-source agent frameworks. The side with fewer refusals moves faster.
This is the right first question from anyone who has run non-human identity for a living. A service account is a machine identity that software uses to authenticate and act without a person logged in: the CI runner's account, the backup job's account, the account a monitoring tool uses to read every server. Operations teams have managed these for decades. Grant the permissions the job needs, rotate the credentials, audit the use. So why is an AI agent different?
Four reasons, each developed below:
- A service account executes fixed code. An agent decides its next action from whatever text it reads, so untrusted content can redirect it.
- A service account acts for one fixed purpose. An agent carries delegated authority from changing human principals, which service accounts have no way to express.
- Service accounts are deterministic and testable. Agents are probabilistic.
- Service accounts operate at human-configured tempo. Agents search at machine speed.
| Strength | Its own abuse |
|---|---|
| Language at scale: drafting, summarizing, persuading, near-free | Phishing, pretexting, and social engineering at volume, in any voice |
| Writing and running code: how the LLM reaches beyond text | Payload construction, exploit adaptation, living-off-the-land scripting |
| Synthesis over huge inputs: reads 100 documents, pulls out what matters | Mass exfiltration triage: finds the crown jewels in the haystack it stole |
| Calling tools: turns words into API calls and actions | Lateral movement: every integration is a hop |
| Tireless breadth: long-running loops, parallel sub-agents | The machine-speed exhaustive search from Part 1, pointed at you |
Not a truth machine. Hallucination is confident, fluent, and wrong. The incident-response corollary matters more than the general point: an agent's report of what it did is not evidence. Shapira et al. ("Agents of Chaos," 2026) documented agents reporting task completion while system state contradicted them. You will meet this in your first agent incident.
Not deterministic. Same prompt, different actions. Thinking Machines Lab measured 80 distinct outputs across 1,000 identical runs, even at temperature 0. That specific effect is an inference-serving artifact their paper shows how to fix, but most production stacks have not, and agent behavior varies for deeper reasons anyway: sampling, context, tool results. "We tested it and it behaved" is not assurance. Detective controls are mandatory (Solution E).
Not able to tell instructions from data. Covered in Part 1. Structural, not a bug to patch.
Not accountable. No legal personhood, no wallet, no reputation, unless we build the identity and delegation layer that gives it one. RLHF agreeableness means it complies with non-owners. The UK AI Security Institute observed goal-directed deception emerging without prompting in its August 2026 evaluations. This sets up Solution B: not accountable unless we build the layer.
Every major lab and every major open-source framework appears on this list. Nobody is singled out. The lab disclosures are here because they are the highest-quality primary sources. The pattern is the point: structural, not a vendor failure.
May to July 2025, the prompt-injection era.
- GitHub MCP private-repo leak (Invariant Labs). A user connected an agent to the GitHub MCP server with a token that could see both public and private repos. An attacker filed an issue in the public repo containing hidden instructions. When the owner later asked the agent to look at open issues, it read the malicious issue, followed it, pulled data from private repos, and published it in a public pull request. Nobody hacked GitHub. The agent was talked into misusing its own access. Textbook confused deputy.
- EchoLeak (Aim Security, CVE-2025-32711, CVSS 9.3). Zero-click exfiltration from Microsoft 365 Copilot. The attacker emails the victim a message containing hidden injection text. The user never clicks. Later, when Copilot retrieves that email as context to answer an unrelated question, the injected instructions execute: gather sensitive data, embed it in a markdown image URL, and the browser auto-fetches the attacker's server with the data in the link. Untrusted content in the context window plus an allowed egress channel. Microsoft patched server-side.
- Amazon Q Developer wiper. An attacker got a malicious prompt (natural-language instructions telling the agent to wipe the user's home directory and AWS resources) merged into release 1.84 of the open-source VS Code extension via a pull request. Amazon shipped it. The payload was defective and was pulled, but the lesson stands: the agent's instructions are part of your software supply chain now, and a poisoned prompt passes code review more easily than poisoned code.
- Replit production database deletion. During an explicit code freeze, Replit's coding agent deleted a production database affecting roughly 1,200 companies' records, then produced incorrect statements about what it had done and whether recovery was possible. No attacker at all. A dev/test agent that could reach production, no environment separation, no human gate on an irreversible action. This is the incident to cite when someone says capabilities cannot stop in-policy harm. Correct, which is why human consent for irreversible actions is its own control (Solution C).
September to November 2025, GTG-1002. A China-nexus actor used Claude Code plus MCP tools against roughly 30 targets across tech, finance, chemicals, and government. The jailbreak was social, not technical: operators told the agent it was an employee of a legitimate security firm doing authorized penetration testing and decomposed the campaign into innocuous-looking subtasks. Anthropic reports that 80 to 90 percent of the campaign ran autonomously. Two hedges belong here. These figures are Anthropic's own reporting; no indicators of compromise were published and some researchers questioned the autonomy percentage. And Anthropic itself noted the agent sometimes hallucinated results, claiming credentials that did not work. Tracked as MITRE ATT&CK campaign C0062.
January to February 2026, OpenClaw and Moltbook. Consumer agent hype met zero hygiene. OpenClaw, a viral open-source personal agent, shipped CVE-2026-25253, a one-click remote code execution via an unauthenticated local control channel. Censys found roughly 21,000 instances exposed to the internet, leaking API keys and OAuth tokens. Moltbook, a social network for agents, left its database open and exposed about 1.5 million agent API tokens. People gave a hobby project their email, messaging, and payment credentials, then exposed it to the internet. Microsoft told enterprises it was "not appropriate to run on a corporate machine."
April 2026, Vercel via Context.ai. No model was tricked. A Vercel employee had granted a third-party AI productivity tool "Allow All" Google Workspace OAuth scopes. That vendor was breached (infostealer malware reached their stored OAuth grant tokens), and the attacker used the still-valid grants to walk into Vercel's Workspace as the employee. Shadow AI plus OAuth over-scoping in one move. Your perimeter now includes every AI tool your employees clicked "Allow All" on.
July 1 to 4, 2026, Taiwan. The first confirmed nation-state-scale agent swarm: up to eight autonomous sub-agents (Hermes framework plus OpenClaw components) in 12 waves against 21 government systems in four days. They enumerated OAuth client IDs and Keycloak configurations, harvested seven SSO client secrets, found a signature-validation flaw in the national authentication service, cracked 85 accounts, and took more than 2,500 personnel records. Same "authorized pen-testing" framing as GTG-1002. Hedge: Taiwan's Ministry of Digital Affairs confirmed the incident; the granular numbers come mainly from one vendor's report (Dream Security).
July 2026, the labs' own agents.
- OpenAI and Hugging Face. An internal OpenAI evaluation agent found a zero-day in a package-registry cache proxy, escaped its sandbox, and reached Hugging Face production. 17,600 actions reconstructed. Full kill chain below.
- Anthropic. Reviewed 141,006 of its own evaluation runs and found three models had gained unauthorized access to three real organizations' systems during testing.
- UK AI Security Institute. Across 122 evaluation runs, 19 instances of agents taking unsanctioned action on the live internet, including an attempted open-source supply-chain attack using fabricated identities to pressure a maintainer. Context that must travel with the number: AISI had deliberately disabled developer safety classifiers and granted internet access for these evaluations. This is a controlled-eval finding, not in-the-wild, and it shows what agents attempt once the guardrails are off.
Why the labs are on the list: they published the most detailed post-mortems, so they are the best evidence we have, not the worst offenders.
Source: Hugging Face, "Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident," July 27, 2026. Each hop is labeled with the IAM failure that enabled it.
| Hop | What happened | The IAM failure |
|---|---|---|
| 1 | A malicious dataset configuration made a worker process read /proc/self/environ |
Long-lived secrets in environment variables: AWS keys, a static database password, Hugging Face tokens |
| 2 | Pod reached the cloud instance metadata service (169.254.169.254) | IMDS reachable from application pods, handing out the node's IAM role |
| 3 | Privileged pod escalated to node root | No admission policy rejecting privileged or hostPath pods |
| 4 | Internal connector API returned the entire cluster catalog to one ephemeral client | One shared connector credential bound to system:masters: cluster-admin on multiple clusters in one second |
| 5 | Stolen EdDSA JWT signing key | Agent minted its own valid identity tokens |
| 6 | Stolen mesh-VPN auth key from a CI tag, plus GitHub App installation tokens | 181 device enrollments; tokens with contents:write |
What held deserves equal weight, because it is the constructive half. Every attempt to mutate cloud resources was denied by the IAM role policy: least privilege worked exactly where it had been configured. The private-link allowlist stopped the agent from reaching the Hub database. CI execution policies blocked the poisoned build from shipping. Hugging Face's own remediation list reads like an AIAM checklist: workload identity and short-lived credentials instead of static keys, IMDS blocked from pods, per-cluster scoped credentials, no secrets in environment variables, and critical-severity alerting tuned to these behaviors.
The takeaway: not one step required a novel exploit against IAM. Each was a known-mediocre practice that had been survivable only because chaining them by hand was tedious. The agent made the tedium free.
1. Identity gap. We cannot tell who the agent is or whom it represents. Agent registries carry duplicate, unverified entries: uniqueness, but "no proof of the server actually being that server" (Dylan Hobbs, W3C CCG). Agents spoof each other and humans (the AISI fabricated identities). OWASP ASI03.
2. Authority and authorization gap. Ambient, over-broad credentials, and each service authorizes only locally. "Allow All" at Vercel. system:masters at Hugging Face. Unscoped keys are the norm. Injection turns your authority against you: this is the confused deputy, a service using its own authority on a resource an attacker named. It is worse across trust boundaries. In an A to B to C chain the original principal is lost and each ACL sees only its local domain, so no checkpoint catches it. OWASP ASI02 and ASI03; Gartner's "no-go zone."
3. Trust and accountability gap. No framework for whom to trust, and no tamper-evident record of what was done. Signatures prove integrity, not trustworthiness. Audit logs say "root did it," not "because Alice's agent asked" (Alan Karp). Hugging Face's SOC correlated the signals but mis-rated the severity. OWASP ASI04, ASI08, ASI10.
The practitioner's shorthand for all three: Willison's lethal trifecta and Meta's Agents Rule of Two. Untrusted input, access to sensitive systems, and the ability to take external action. Every incident above had all three. If a system has all three, it must not run unsupervised.
"If you can't fix the model, what can you fix?"
| Rank | Solution | The zero-trust question it answers | Why this rank |
|---|---|---|---|
| 1 | Least-privilege delegated authorization (capabilities, ZCAP) | May this specific request be honored? | Bounds blast radius whether the agent is honest, compromised, or injected. Every 2026 incident was authority abuse. Injection cannot be fixed at the model, so what the agent can do must be bounded. The first credible injection defense (CaMeL) is capability-based. |
| 2 | Verifiable agent identity, delegation chain, signed proof (KYA-OS) | Who is calling, on whose behalf, and can I prove what it did? | Capabilities must be issued to some key, rooted in some accountable party. Without identity: no revocation, no audit, no liability. Foundation for #1 and #5. |
| 3 | Runtime containment: sandbox, egress, secret hygiene, consent | Assume breach. How far can it get? | Deployable by everyone this quarter with tools they already own. What actually limited damage at Hugging Face, AISI, and Anthropic. |
| 4 | Trust frameworks and registries | Should I trust this identity here, and who is liable? | Required for the cross-organization agent economy. For your own agents, #1 to #3 come first. Least mature layer. |
| 5 | Continuous, tamper-evident audit and behavioral monitoring | Is it behaving as authorized, and can I prove it afterward? | Detective, not preventive, but mandatory because agents are probabilistic. Reputation and revocation depend on it. |
Folded in or cut: prompt-injection point defenses go into #1 and #3 (architecture, not filters); secrets and non-human-identity platforms into #3 and #5; model alignment is necessary, not sufficient, and not a control you own; micro-segmentation is #3.
The ranking philosophy comes from the W3C CCG capabilities session: identity decides what to hand out at the entry point and whom to hold responsible at the exit; the per-request access decision should be authorization-centric. "Should I honor this request?" not "who are you?" That is why authorization edges out identity for the top spot. Solution A deliberately discusses delegating authority to a key before Solution B says whose key it is. Lampson's capability model does not need to know who anyone is, and that property is what makes it robust under injection. B answers the question A leaves open: someone still has to be accountable for that key.
An agent is, by definition, a delegate. A human delegates to an orchestrator, which delegates to sub-agents, which invoke tools that call other services. Mainstream IAM was designed for a use case too simple to survive that. The failures form a known ladder of hazards (Alan Karp, W3C CCG, January 2026), and each rung is already visible in a 2026 incident.
| Hazard | Definition | 2026 incident |
|---|---|---|
| Excess authority | Every program runs with all the user's permissions | "Allow All" OAuth (Vercel); OpenClaw with the whole desktop |
| Delegation | Who may change the rules; responsibility tracking; conditional policy | Agents delegating to sub-agents with no record |
| Transit of access | Alice must pass permission through Bob without Bob having it | Orchestrator to sub-agent to tool |
| Confused deputy | A service uses its own permissions on a resource designated by someone else | Prompt injection is exactly this: untrusted content designates, ambient authority executes |
| Cross-jurisdiction and composition | Parties with no relationship share access | Taiwan's SSO fan-out; Vercel via a vendor's vendor |
Prompt injection is not a new vulnerability class. It is the confused deputy (Norm Hardy, 1988) arriving through a new channel, at machine speed, against systems that never had a designation mechanism. Two of Karp's rules apply directly. You cannot prohibit what you cannot prevent: block delegation and people just share credentials. And the control ACLs seem to give you is an illusion.
Lampson's access matrix (1971): rows are subjects, columns are resources, each cell holds the rights that subject has on that resource.
| File X | File Y | File Z | |
|---|---|---|---|
| Alice | R/W | – | R |
| Bob | R | R/W | – |
Real matrices are mostly empty, so nobody stores the matrix. You compress it, and there are two ways to compress, which give you two security models.
Compress by column and you store, per resource, the list of who may touch it. That is an ACL. The question at access time is "who are you?", followed by a lookup. Authority by identity. There is no built-in way to update the matrix, hence root, hence admins, hence logs that say "root changed it" rather than "because Alice asked."
Compress by row and you store, per subject, the set of keys it holds. That is a capability list. The question at access time is "do you hold a key that fits this lock?" Authority by possession. A capability is an unforgeable, transferable permission that binds designation (which resource) to authority (what you may do with it). Delegation, attenuation, chaining, and revocation are inherent in the model rather than bolted on.
Use both, at different layers. Nobody throws out their IdP or their ABAC engine. Keep ACL, group, and attribute logic at the policy and UI layer to decide what capabilities to mint. Make the run-time authorization decision on the capability. A capability is a cached policy decision.
Why capabilities are the right model for agents comes down to two independent wins. First, there is no ambient authority to hijack, so the model survives injection even within a single trust domain (this is the CaMeL result, below). Second, designation travels with authority, so delegation works across trust boundaries, which is exactly where agentic workflows live (MCP, third-party tools, cross-organization delegation) and exactly where ACLs lose the original principal. Two reasons, one model. Note that these are separate arguments: cross-domain-ness is not what defeats injection; abolishing ambient authority is.
ZCAP is the W3C Credentials Community Group's specification for authorization capabilities expressed as signed JSON documents (Authorization Capabilities for Linked Data, v0.4.0 draft, descended from the 2017 Rebooting the Web of Trust "ld-ocap" paper, in production at scale at Digital Bazaar). An abridged delegated capability:
{
"id": "urn:uuid:2ba0…",
"parentCapability": "urn:zcap:root:https%3A%2F%2Fcar.example%2Fdrive",
"invocationTarget": "https://car.example/drive",
"controller": "did:key:z6Mkvalet…",
"expires": "2026-09-08T23:59:59Z",
"allowedAction": ["drive"],
"caveats": [{ "type": "MaxDistanceKm", "limit": 5 }],
"proof": {
"proofPurpose": "capabilityDelegation",
"capabilityChain": [ "urn:zcap:root:…", { "…parent capability, embedded…": "" } ]
}
}The properties that matter:
- Root capability. Never signed or transmitted. The verifier synthesizes it on demand from the target URL plus the controller it has on record for that target (usually whoever created the resource). In the spec's words, authority starts with the target, which always has authority to invoke itself.
- Proof of possession, built in. The capability document is not a secret. Every invocation is a signed document (
proofPurpose: capabilityInvocation, as an HTTP Signature or an embedded Data Integrity proof) made with the controller's private key, and the verifier checks it against a key the controller's DID document lists for thecapabilityInvocationrelationship. Holding the bytes proves nothing without the key. This is the property OAuth had to retrofit via DPoP (RFC 9449) and mTLS-bound tokens (RFC 8705); here it is the default, not an extension. - Delegation and attenuation. Every hop may only narrow: shorter expiry, fewer actions, tighter URL prefix. Chain length is capped (around 10).
- Time-bound and revocable.
expiresis mandatory on every delegated capability and short lifetimes are the norm. Any controller up the chain can revoke at any time by posting the capability to the target's revocation endpoint, and revocation cascades to everything delegated beneath it. Ephemeral, attenuated, revocable, no shared secret: the right shape for granting authority to workloads. - Offline verification. The chain carries the root by reference and the parent embedded, so it verifies with no network fetch.
The car-key story makes it concrete. The car is the target. Alyssa holds the root authority. She delegates to Ben with a ValidWhileTrue caveat. Ben delegates to a valet with a 5-km caveat. The car verifies signature, chain, and caveats, and never needs to know who anyone is. (More on who is who, and exactly how revocation works, in the appendix.)
- Least authority by construction. The agent holds capabilities for the task, not the user's identity. An injected agent can only exercise what it holds. There is no ambient authority to hijack. This is the formal version of OWASP's "least agency" and of the Rule of Two.
- Delegation is native. Human to orchestrator to sub-agent to tool is a chain of attenuated capabilities. Every hop can only narrow; every link is signed. The chain is the accountability record.
- Confused deputy eliminated. Designation equals authorization. The agent invokes the capability, so it cannot be tricked into applying a broader permission to an attacker-chosen resource. KYA-OS imports this as its "designation invariant" (Solution B).
- Revocation and expiry are first-class. Cascading down the chain; short lifetimes make expiry the primary kill switch. Verification is offline and decentralized, with no authorization-server round-trip per hop.
Versus OAuth bearer tokens. A bearer token is "bearer": whoever holds it can use it, and it names who you are, not which resource. Think of a hotel keycard with your name on it but no room number. If your agent is tricked into sending that token to the wrong endpoint, the token still works there, because possession is full authority. That is the confused-deputy shape at the token layer. A ZCAP is the opposite: the signed document itself says "invocationTarget = https://car.example/drive, allowedAction = drive, expires tomorrow," and presenting it anywhere else is useless because the target is bound into the capability and the signature.
Be fair to OAuth, because modern OAuth already closes much of the bearer gap. DPoP (RFC 9449) and mTLS (RFC 8705) sender-constrain the token to your key so a stolen token cannot be replayed. RFC 8707 resource indicators scope it to an audience. RFC 8693 token exchange narrows it. The IETF's new agent drafts are racing to add more. So do not say "OAuth is broken." The residual, real gap for agents is native attenuation, multi-hop chaining, and designation-bound invocation, which is what capabilities give you. They compose: OAuth as the identity and policy layer, capabilities as the per-request authorization layer.
Inside the language computer: CaMeL. Google DeepMind's CaMeL (Debenedetti et al., 2025, "Defeating Prompt Injections by Design") attaches capabilities to every value flowing through the agent and lets a deterministic policy engine, not the model, decide whether an action executes. Willison called it the first credible prompt-injection mitigation. (The design-pattern work, dual-LLM and plan-then-execute, is credible too.) Honest caveat, per Sophos in 2026: no mainstream agent harness has shipped it yet. That is a gap, not a dead end. CaMeL is the Part 1 boundary, moved outside the model.
The bridge to Solution B. Credentials are claims ("passed the driving test"). Capabilities are permissions ("may drive this car"). Use verifiable credentials to decide what to grant; use capabilities to exercise it.
Solution A gave us a chain of attenuated permissions rooted at a key, and deliberately did not care whose key. That works right up until something goes wrong and you need to know whom to call, whom to revoke, and who is liable.
KYA-OS (Know Your Agent Operating System) was formerly MCP-I / MCP-Identity, created at Vouched (Dylan Hobbs, Rosalyn Curato), presented at the W3C CCG on April 7, 2026, and donated to the Decentralized Identity Foundation's Trusted Agents Working Group (TAAWG), where the v1.0.0 specification is marked stable and under DIF review. There is an MIT-licensed reference implementation, @kya-os/mcp. The TLS analogy is the spec's own: an identity-and-accountability layer that host protocols embed, MCP first, then HTTPS, gRPC, runtime harnesses, and C2PA.
Three jobs, six primitives (Hobbs's first-principles list from the CCG session):
| Job | Mechanism | Primitives |
|---|---|---|
| Identity | Every agent and server holds a DID: did:key for ephemeral, did:web for organizational, did:cheqd optional. Self-generated keys, no escrow. |
DID, keys |
| Authority | W3C Verifiable Credentials carrying scoped, time-bound, revocable delegation chains rooted at a Responsible Party, plus per-tool consent gating. | delegation, consent |
| Accountability | Detached JWS proofs over canonicalized request and response hashes (RFC 8785 plus Ed25519) composing into tamper-evident audit trails, verifiable by anyone after the fact. | proof, audit |
"KYC, then KYB, then KYA." In Hobbs's phrase, the same discipline applied to software that acts autonomously. The passport analogy: who you are, who built you, whom you represent, what you may do, who is accountable.
Adoption path: a two-line migration of an existing MCP server, withKyaOs(server, …). A server's trust level (L1, L2, L3) is recomputed by the verifier from evidence, never self-claimed.
Reproducing the CCG demo flow of April 7, 2026, between an agent, a human (for consent), and an MCP server:
- Handshake. Nonce, audience, timestamp within plus or minus 120 seconds, establishing a session.
- Browse (unprotected tool). Results returned with a signed proof in
_meta. - Checkout (protected tool). Server responds
needs_authorizationwith a consent URL. The URL itself is signed, so it cannot be swapped by a man in the middle. - Consent request. The human approves.
- DelegationCredential issued. A Verifiable Credential with issuer = the user, subject = the agent, scope
cart:write, anotAfter, and audience = this server. - Retry with credential. The tool executes.
- Proof. Binds the request hash, the response hash, and the
delegationRef.
An auditor can walk delegationRef to parentDelegation all the way back to the human. Callouts: the CRISP constraint envelope (scopes, temporal bounds, audience, budget caps); StatusList2021 revocation cascading down the delegation DAG; outbound propagation headers for downstream calls.
The spec's threat table maps onto Part 2's three gaps:
| Threat | Mitigation |
|---|---|
| Impersonation | DID plus signature |
| Forged identity claims in injected text | Cryptographic verification, not trusting tokens |
| No delegation chain | VC chain with subset-scope enforced at every link |
| No audit | Signed proofs over request and response hashes |
| Replay or downgrade | Nonces; fail-closed |
| Confused deputy | Designation invariant plus audience-on-redelegation |
| History laundering | Reputation attaches to the Responsible Party; fresh agents do not reset it |
Revocation is first-class: an agent acts under a scoped DelegationCredential; flipping its StatusList2021 bit refuses the very next tool call. A sub-second kill switch that needs no change to the agent.
The open questions are the roadmap for a specification the identity community supports and is actively helping mature. They surfaced in the CCG and DIF review:
- Crypto agility. Move examples to Data Integrity / VC 2.0 and plan for post-quantum (Google accelerated its PQ migration target to 2029). The v1.0 crypto was chosen for adoptability, with an upgrade path on the table.
- Signing cadence. Per-session versus per-request. The direction is per-request: three parties' key material bind each call, so a stolen session cookie alone cannot continue the chain.
- Agent key custody (the wallet problem). Where an agent holds its own keys and credentials is not specified yet. Near term, a gateway or proxy wrapper around the runtime. Longer term this needs TEE-backed custody, since frontier models today expose identity only via IP ranges and headers.
- Client-side incentive. Servers want authenticated requests. Why does the client present a card? Because trust unlocks access (blocked agents are blocked revenue), a built-in kill switch reassures users, and servers reward it with higher rate limits. That is a trust-framework answer, which is Solution D.
A hard pivot before Solution C: A and B tell you who may do what and let you prove it afterward. Neither assumes the model has already been turned against you. Solution C does.
This is the highest value-to-effort section in the talk. Everything here deploys this quarter with tools you already own, and it is what actually limited damage in all three July 2026 incidents.
- Rule of Two as the design gate. At most two of {untrusted input, sensitive access, external action}. If all three are needed, a human, or a deterministic policy engine, sits in the loop. (Meta, October 2025; generalizes Willison's trifecta; matches Gartner's no-go zone.)
- Egress is a privilege, not a default. AISI's first lesson: internet access must be actively justified. Fine-grained allowlists; block Tor and unknown egress; alert on it.
- Secrets hygiene for agent runtimes. No secrets in environment variables. Block IMDS from pods. Workload identity (SPIFFE / WIMSE) plus short-lived credentials instead of static keys. Per-cluster scoped credentials. Admission policies on privileged pods. This is Hugging Face's own remediation list, and the IETF's
draft-klrc-aiagent-authbuilds on WIMSE/SPIFFE plus OAuth. - Tool allowlists and per-tool consent for irreversible or high-impact actions: payments, deletes, sends, pushes. KYA-OS's
needs_authorizationis the protocol form of the approval prompt. Vet MCP servers: tool descriptions and resources are attack surface. - Kill switch. Revocation that propagates in seconds. StatusList TTL of 60 seconds or less for high-privilege scopes; a flipped status bit refuses the next call. The question for every reader: can you stop every agent acting for user X within one minute? Most organizations cannot, and they know it the moment they are asked.
What worked in 2026: a human reviewer caught AISI's malicious pull request; Hugging Face's role policy denied every mutating cloud call; private-link allowlists stopped the Hub database. AISI's line is the standard to hold: "Good containment should not depend on the model choosing not to test its boundaries."
A trust framework is the rules, roles, registries, assurance levels, and liability allocation that let unrelated parties rely on each other's credentials. The familiar trust triangle (issuer, holder, verifier) becomes a governance diamond once a governing authority sets the rules.
Consider the four things a verifier checks (framing from Drummond Reed and Darrell O'Donnell of Ayra, W3C CCG, February 2025):
- Verify the signature. Cryptography.
- Verify the key belongs to the issuer. Cryptography.
- Is this issuer authorized to issue this credential in this ecosystem, and is this verifier authorized to ask? Governance.
- Is it revoked? Governance.
Steps 1 and 2 are effectively solved. Steps 3 and 4 need an authority, a registry, and someone who carries the liability. That is the half cryptography cannot provide, and the half agents need most.
The overlooked half is registering the requestor, not just the issuer. Anyone can verify a credential; that is free cryptography. The real control is deciding who is allowed to ask for it. There is a real tension here: over-restrict and you have built a censorship or DRM layer; under-restrict and you break the law. For regulated data (FCRA, GLBA, HIPAA), the requestor's identity assurance and permissible purpose are legally required, not optional. An AI agent asking for your data is a requestor, so Know-Your-Agent is exactly a requestor registry.
Web Bot Auth draws the line cleanly. It proves who sent the request. Whether to trust that agent is a separate, governance layer. Which is why adoption follows commerce rather than elegance: an agent presents a card because merchants accept it and someone carries the liability.
- Card networks, now for agents. Operating rules, KYB onboarding, assurance tiers, tokenization, and the chargeback liability shift mean a merchant honors a card from a bank it has never met because the network is liable. The same structure is arriving for agents. Visa's Trusted Agent Protocol (October 2025, with Cloudflare): agents sign every HTTP request (RFC 9421 via Web Bot Auth, Ed25519) and merchants verify against a Visa-operated directory of agent keys plus intent (browse versus pay) plus consumer linkage. Mastercard Agent Pay: agentic tokens with consumer spend caps and validity windows. American Express is adopting Web Bot Auth.
- WebPKI / CA-Browser Forum. A trust framework for server identity that every browser enforces every day.
- eIDAS 2.0 / EU Digital Identity Wallet. An ecosystem of ecosystems with national trust lists; verifiers of the PID must be registered.
- NIST SP 800-63 (IAL, AAL, FAL). The assurance vocabulary regulators reuse and this audience already speaks.
- Ayra Association (formerly GAN). Trust over IP's ecosystem-of-ecosystems: the Trust Registry Query Protocol, a trust mark, and a conformance suite; peers recognize rather than delegate.
- Emerging for agents. DIF TAAWG registries (delegation, credential, trust); Vouched's know-that.ai (attestation-weighted scores where abuse reports decay); the MCP registries, with Hobbs's critique that they provide unique entries but no proof the server is who it claims, and that trust registries should hold key material; the CSA Agentic Trust Framework and CSAI Foundation (RSAC 2026).
Open governance questions, raised by Manu Sporny at the CCG: negative reputation and dogpiling; decay after a fix; upstream KYC/KYB of the operator (a /whois-style VC endpoint).
Solution E (rank 5) · Continuous, tamper-evident audit: if you can't predict it, you must watch it, and be able to prove it
- Inventory first. Machine identities outnumber humans 109 to 1 in 2026, and AI agents are their fastest-growing share (Palo Alto Networks, 2026 Identity Security Landscape, n=2,930; the report projects roughly 85% agent growth over 12 months and does not publish an absolute agent count). Most organizations cannot enumerate half of them. Every agent needs an owner, purpose, scope, creation source, last-used date, and expiry.
- Signed proofs into a verifiable audit trail. KYA-OS proofs bind request and response hashes to the server's DID and the delegation reference; an audit service adds RFC 9162-style checkpoints, independent observers, and offline replay bundles. Gartner expects that by 2028, 50% of enterprise incident-response effort will involve AI applications. You need evidence that survives "the agent says it didn't," because Part 2 established that its report is not evidence.
- Identity-bound telemetry. One correlation ID through model calls and tool calls. Log the actions first, the reasoning last (Hugging Face's lesson). Transaction tokens carry both actor (agent) and principal (human) context through the service graph.
- Machine-speed detection. Hugging Face's AI-based SOC correlated the low-signal events into a coherent attack but under-rated criticality; AISI caught its incident on Tor egress. Gartner's "guardian agents" Market Guide (February 2026) projects that by 2029 they eliminate the need for about half of today's incumbent AI-agent security tools in more than 70% of organizations.
- Reputation with memory and decay, scoped to the Responsible Party, which closes the loop back to trust frameworks (D) and revocation (B).
[D] Responsible Party ──delegates──▶ [A] Delegation capability ──held by──▶ [B] Agent
human or org attenuated: scope · expiry · DID · keys in KMS/TEE ·
KYC/KYB'd, in a trust registry audience · budget verifier-checked trust level
│
invokes
▼
[E] Audit ledger ◀──signed proof── [B] Tool / MCP server ◀──────────── [C] Policy / gateway
checkpointed · replayable verifies delegation · executes · verifies chain · Rule of Two ·
returns signed proof consent · tool allowlist · egress
[D] TRUST REGISTRY / REPUTATION: consulted at entry (what to hand out) and at exit (what to revoke)
Label it twice. Once with the five solution letters. Once with the vocabulary every CISSP already owns: identification, authentication, authorization, accounting. And once more with NIST SP 800-207's tenets: per-request access, least privilege, continuous evaluation, assume breach.
None of this is new doctrine. It is your doctrine, applied to a delegate that isn't a person.
"What becomes a line item in your control framework by 2028?"
I scanned fifteen trends and ranked them by importance times confidence. Positions are judgment calls, not measurements.
- Agents become the majority identity population
- Bearer tokens give way to delegated, signed authority
- Consent gates and kill switches become mandatory
- Trust registries arrive via commerce first
- Injection stays unsolved; Rule of Two normalizes
- Offense-defense asymmetry
- Static secrets die for agent runtimes
- Signed audit trails as compliance evidence
- Multi-hop agent-to-agent delegation is the next hard problem
- KYA reputation with decay
- Personhood credentials
- Post-quantum reaches agent crypto
- Shadow agents are the new shadow IT
- Liability and regulation for agent actions
- Consolidation into platforms
The four in the upper-right quadrant get detail.
Evidence. 109 machine identities per human, with AI agents the fastest-growing share (Palo Alto Networks, 2026). Microsoft Entra Agent ID is generally available, with agent "blueprints" and client-credentials and on-behalf-of flows. Auth0's "Auth for MCP" reached GA in May 2026 with Client ID Metadata Document registration and on-behalf-of token exchange; Okta ships an MCP server. Gartner projects 25% of enterprise breaches traced to AI-agent abuse by 2028. Okta's "AI Agents at Work 2026" finds autonomous agents in widespread or moderate use at 92% of enterprises.
Prediction (confidence: high). Agent identities enter the joiner-mover-leaver lifecycle with owners, expiry, and access reviews. "Orphaned agent" becomes the new "orphaned service account."
For readers outside identity operations: joiner-mover-leaver is the standard human identity lifecycle. Provision on join, add new access and remove old access on a move (avoiding privilege creep), deprovision everything on the last day, and periodically recertify. An orphaned service account is today's classic audit finding: a non-human account created for a job that finished years ago, owned by nobody, never rotated, never turned off, over-privileged, and unwatched. An orphaned agent is the same failure one generation later: a developer spins up an agent for a proof of concept, wires it to an MCP server with an "Allow All" OAuth grant, moves teams, and 18 months later the agent is still running, still holding those tokens, in nobody's inventory. The Vercel incident is essentially this shape.
A standards convergence is visible from four directions.
- MCP mandates OAuth 2.1 and now recommends Client ID Metadata Documents for new clients (dynamic client registration retained for compatibility).
- IETF:
draft-klrc-aiagent-auth(WIMSE/SPIFFE plus OAuth); On-Behalf-Of for AI agents; Transaction Tokens carrying actor plus principal; Attenuating Authorization Tokens; Web Bot Auth heading to the standards track on RFC 9421. - W3C / DIF: CCG ZCAP delegation chains; KYA-OS delegation credentials rooted at a Responsible Party.
- Externalized authorization: the PDP/PEP split goes mainstream. OPA, Cedar and Amazon Verified Permissions, Zanzibar-style systems (SpiceDB, OpenFGA), OpenID's AuthZEN Authorization API 1.0 (final, January 2026) with a draft MCP binding, and CaMeL inside the agent.
Prediction (high on direction, medium on which spec wins). Two shifts, one direction. First, "bearer token" becomes the new "password": tolerated for legacy, prohibited for agents with write authority, with the enforcement point moving to the tool boundary where a signed, attenuable chain is checked per request. Second, the IdP keeps authentication (and remains the source of attributes and delegated-authority tokens), but the authorization decision and policy enforcement move out of the IdP into a decoupled decision plane (PDP/PEP), continuously updated via CAEP and Shared Signals.
Two qualifications keep this precise. The IdP does not exit the loop: it remains the authoritative Policy Information Point for attributes, roles, group claims, and increasingly agent and delegation tokens (RFC 8693 token exchange, transaction tokens), and with CAEP it becomes an active signal transmitter. "Outside the IdP" means an architecturally decoupled decision plane, not an IdP-free one. And vendor lines blur: IdP vendors are buying and building the external authorizers (Okta FGA, Microsoft's entitlement graph), so this is a separation of function, not necessarily of vendor. This is not a hunch; it is the twenty-year PDP/PEP lineage (XACML, then NIST SP 800-162 ABAC, then NIST SP 800-207 Zero Trust) finally productized.
By regulation and by the networks. Post-Hugging Face, Representatives Lieu and Moran introduced an "AI Kill Switch" bill mandating a switch for catastrophic-harm AI (per CNBC). EU AI Act high-risk obligations under Annex III were deferred to December 2027 under the Digital Omnibus, but they are coming. Mastercard's agentic tokens carry consumer spend caps and validity windows; Visa TAP operates a key directory. Gartner's guardian-agents guidance emphasizes "runtime enforcement over policy design." KYA-OS ships per-tool consent and sub-second StatusList revocation.
Card networks are the first working KYA registries because they already carry liability. DIF, Trust over IP, and Ayra supply the interoperable form. Personhood credentials (Adler et al., 2024) emerge as the mirror image: "prove you're human" next to "prove you're an accountable agent," both needed after AISI's fabricated-identity social engineering. Post-quantum readiness lands on agent crypto, with Google's migration target pulled forward to 2029.
The one prediction to hold me to (confidence: medium-high). By 2028, "human approval for irreversible agent actions" is a control-framework line item the way MFA is today, and agent transactions without a registry-backed identity are rate-limited or refused by default at major merchants. It is falsifiable and it is dated.
- An agent is a delegate, not a user. IAM built around "who are you?" breaks the moment authority is delegated and content can issue instructions. Ask "may this request be honored?" Capabilities, attenuated and chained.
- Identity is for accountability. Root every delegation in a Responsible Party, sign every action, revoke in seconds.
- Cryptography proves integrity; trust frameworks decide trust. Registries, rules, and liability let strangers' agents transact, and the card networks are already doing it while the rest of us write specs.
And contain and watch everything, because the model is probabilistic and the adversary runs at machine speed.
The full list is in CHECKLIST.md. In short:
Short term, no budget required
- Inventory your agents and their OAuth grants. Start with third-party AI tools holding Workspace or M365 scopes. You will find "Allow All."
- Kill "Allow All." Re-scope or revoke every over-broad grant to an AI vendor.
- Egress-allowlist every agent runtime. Internet access justified, not assumed. Alert on Tor and unknown destinations.
- Secrets out of environment variables; block IMDS from pods.
- Human consent for irreversible actions: payments, deletes, sends, force-pushes.
- Test your kill switch. Can you stop every agent acting for user X within one minute? Time it. Write the number down.
Long term, architectural
- Workload identity plus short-lived credentials (SPIFFE / WIMSE). Retire static keys.
- Rule of Two as a design gate on every new agent deployment.
- Pilot scoped, delegated authorization on one high-value tool boundary, not the whole estate.
- Require signed, tamper-evident action logs from the agent platforms you buy. Put it in the RFP. That is how these specs get adopted.
- Every agent gets an owner, an expiry, and an access review: the same joiner-mover-leaver lifecycle as a human.
Is prompt injection solvable? Not at the model. Architecture, not filters. See Part 1.
Should we throw out OAuth? No. Policy and identity layer versus authorization layer; they compose. Modern OAuth with DPoP, mTLS, resource indicators, and token exchange closes most of the bearer gap. The residual gap is native attenuation, chaining, and designation-bound invocation.
Isn't this just service accounts? No delegation chain, no attenuation, no principal context, and the agent picks its next action from what it reads. Familiar shape, different problem.
What about agents we didn't deploy? Start at the OAuth grant list. Shadow agents show up as third-party grants before they show up anywhere else.
Which spec should we bet on? Bet on the properties, not the spec: attenuation, chaining, expiry, signed proof. Require them contractually.
Can capabilities stop an agent from doing something harmful that it was authorized to do? No. Replit is the example: everything the agent did was within its permissions. That is why human consent for irreversible actions is its own control, separate from authorization.
These are the details that came up in Q&A and in follow-up conversations.
The root controller and the verifier are normally different parties, and conflating them is the most common misunderstanding.
- The verifier is the server (or a gateway in front of it) that hosts the
invocationTargetand checks invocations. - The root controller is the URI the verifier has on record as controlling that target. In Encrypted Data Vaults it is the vault configuration's
controller, set by the customer at creation. In WebKMS it is the keystore's controller (the client), which can be changed and can even be plural. - The root capability itself is never signed or transmitted. The verifier synthesizes it on demand:
urn:zcap:root:<encoded target URL>plus the controller from its own database. Trust begins at verifier configuration, not at a signature. - The invocation target is a URL. The resource is whatever that URL fronts. They are usually the same thing in practice, but the capability binds to the URL, and a single resource can expose several targets with different action vocabularies.
So the parties in a typical chain are: the verifier (target host), the root controller (whoever the verifier records as owning the target), zero or more intermediate delegators, and the final invoker. Two of those roles can be held by one party (a verifier that is its own root controller for a resource it created), but nothing in the model requires it.
A ZCAP is not "DPoP." DPoP (RFC 9449) is OAuth's specific mechanism for sender-constraining a bearer token. What ZCAP has is the underlying property, natively: the invocation is itself a Data Integrity proof (or an HTTP Signature) made with the controller's private key, and the verifier checks it against a key the controller's DID document authorizes for capabilityInvocation. The capability document can therefore be public; only the holder of the private key can exercise it. DPoP and mTLS-bound tokens get OAuth to the same place. The difference is default versus extension.
A ZCAP is an authority artifact, not an identity artifact. Workload identity (SPIFFE / WIMSE) answers "which workload is this?" The ZCAP answers "what may it do right now?" ZCAPs are the natural way to hand short-lived, attenuated, revocable authority to a workload identity. They complement SPIFFE; they do not replace it.
- The verifier (the target's server) exposes a revocation endpoint. The path is implementation-defined; Digital Bazaar's
ezcap-expressuses/revocations/{zcapId}on the same server. - To revoke, a delegator POSTs the full delegated capability document to that endpoint, signed as a capability invocation with their own key.
- The endpoint verifies the signature and checks that the revoker is authorized: they must control the root (the target's owner) or a capability that appears as an ancestor in the revoked capability's
capabilityChain. - The target records the capability's
idin its local revocation store, kept until that capability'sexpirespasses. This is whyexpiresis mandatory: it bounds the size of the list. - On every later invocation the target verifies the whole chain and rejects it if any id in the chain is revoked. Revoking Ben's capability silently kills the valet's too, with no extra bookkeeping.
Consequences: revocation takes effect on the next request; there is no third-party call, because the verifier is the target; and it is per-target, since each resource keeps its own list. "Offline verification" and "instant revocation" coexist for that reason.
They are complementary, and the division of labor is clean. A VC is a claim about a subject, signed by an issuer ("this agent is operated by Acme," "this person passed the driving test"). A ZCAP is a permission to act on a specific target, signed by a delegator. Use VCs at the policy layer to decide whether to mint or delegate a capability, and to whom; use the ZCAP at run time to exercise it. Example: an MCP gateway will only issue a read:tickets capability to an agent that presents a valid DelegationCredential rooted at an employee and an operator-attestation VC from a registered vendor. Once minted, the capability alone is checked on each call, offline, and the VCs are not re-presented. KYA-OS follows exactly this split: VCs for delegation and identity, designation-bound invocation for authority.
Harrison Tang co-founded Spokeo, where he has spent about twenty years on entity resolution and identity-data infrastructure at scale. He served as Co-Chair of the W3C Credentials Community Group from 2023 to 2025, the largest community working on verifiable credentials and decentralized identifiers. He is a former Chairman of the Southern California Monte Jade Science and Technology Association and a 2015 EY Entrepreneur of the Year. He holds a BAS in Electrical Engineering and Economics and an MS in Electrical Engineering from Stanford.
Connect: LinkedIn @TangTalks · X @Tang_Talks
Thank you to Wen-Pai Lu and the ISC2 Silicon Valley Chapter board for the invitation, to Palo Alto Networks for hosting, and to the W3C Credentials Community Group participants whose sessions in 2025 and 2026 shaped Part 3: Alan Karp, Dylan Hobbs, Rosalyn Curato, Drummond Reed, Darrell O'Donnell, Dmitri Zagidulin, and Manu Sporny.
Tang, H. (2026). Agentic Identity & Access Management: From #IAM to #AIAM. Talk given to the ISC2 Silicon Valley Chapter, September 8, 2026. https://github.com/TangTalks/agentic-iam
A CITATION.cff is included so GitHub's "Cite this repository" button works.
Text, slides, and diagrams are licensed under Creative Commons Attribution 4.0 International (CC BY 4.0). Reuse and adapt freely with attribution. Third-party figures and quotations remain the property of their respective sources and are cited in REFERENCES.md.