What can your AI agents do right now? Nobody can answer that.

Ask any organisation to list every action its agents, tokens and app grants can currently perform, and the honest answer is a shrug followed by three days of archaeology. Authority is scattered, tenant bound, and unverifiable by anyone outside the system that issued it. That gap has a name, and it has a shape.

The question that stops the room

The incident review starts the way they always do. Someone has a timeline on screen. An agent, wired into a ticketing system to triage and close duplicates, has closed a batch of tickets it should not have touched, and one of those tickets was a security escalation. Nobody is angry yet. Everyone is curious.

The head of platform asks a reasonable question. Not "how did this happen", which will take a while, but something simpler and, it turns out, much worse.

What else can it do?

The room goes quiet, in the specific way rooms go quiet when a question is not hard but simply unanswerable. The agent has an OAuth grant into the ticketing system, and somebody thinks it was scoped to read and comment, though the consent screen said something broader and nobody kept the screenshot. It has an API key for the internal search index, issued in a Slack thread eight months ago by an engineer who has since moved teams. It runs on a service account in the identity provider, which has a group membership that was inherited from a template. It can call two internal tools through a gateway, and the gateway config is in a repository that three people can edit.

Four systems, four partial answers, no whole. Somebody volunteers to go and find out. It takes until Thursday.

Here is the thing worth noticing. Nothing in that story is a failure of any particular tool. The identity provider correctly listed the service account. The SaaS admin panel correctly showed the app grant. The gateway config was in version control like it should be. Every system did its job. There was simply nowhere that held the answer, because the answer spans all of them and belongs to none of them.

Why can nobody answer the question?

Picture a company where every employee has keys. Real, physical keys, cut over twenty years by different facilities managers. Some open one door. Some open a floor. A few open everything, and nobody remembers cutting them.

There is no key register. There never was. So when you want to know which doors a particular person can open, there is exactly one method available: you walk them around the building and watch them try every door. It works. It takes all day. And the moment you finish, it is out of date, because someone in facilities cut another key while you were on the third floor.

That is the state of agent authority in essentially every organisation running agents today. The identity provider knows which principals exist. Each SaaS tenant knows which grants it issued. The CI system knows which secrets it holds. The gateway knows which tools it exposes. Every holder knows its own slice, no holder knows the whole, and the only way to assemble the picture is to walk the building.

Call the condition Authority Opacity: authority exists, it is real, it is being exercised right now, and it cannot be enumerated, inspected by the human it acts for, or verified by anyone who is not the system that issued it.

Opacity is not the same as sprawl, and the difference matters for what you buy. Sprawl means there is too much authority. Opacity means you cannot see the authority you have. Sprawl is a hygiene problem you can clean up. Opacity is a structural property of how authority is issued, and no amount of cleaning fixes it.

Why do non-human identity inventories not close this?

A category has grown up around this pain. Tools from vendors including Astrix, Oasis, Entro and Veza scan tenants, enumerate service accounts, tokens and app grants, and give you a dashboard. Industry inventories of this kind are where the widely repeated claim comes from that machine identities now outnumber human ones by something like a hundred to one, a ratio that varies enormously by methodology and sector and should be read as an order of magnitude rather than a measurement. We looked at that ratio and its caveats in the 100 to 1 ratio.

These products are useful and I would rather have one than not. They also cannot answer the question in the incident review, for three structural reasons.

They are reconstructions, not records

An inventory is built by scanning from the outside. It infers what exists by asking each system what it holds. That means it can only see systems it has been connected to, with credentials that let it look. The API key in the engineer's Slack thread, the personal access token on a laptop, the agent config in a repository, the grant a contractor made in a tenant you do not own: invisible. Not because the product is bad, but because you cannot scan a system you were never given access to.

They answer "what exists", not "who authorized it"

This is the deeper problem. An inventory tells you that a service account has a role. It does not tell you which human decided that, on what date, under what scope, for what stated purpose, or whether that decision is still meant to be true. Provenance is the thing an incident review needs and the thing a scan cannot recover, because it was never written down in the first place.

Nobody outside can verify a single fact from them

Suppose your agent contacts a supplier's API and says it is authorized to place orders up to a limit. The supplier has two options: believe it, or call you and ask. There is no third option where the supplier checks a cryptographic fact and proceeds. Your inventory is a private dashboard, and a dashboard is not evidence anyone else can use.

And underneath all three: the human, who is the root of every one of these grants, has no view at all. The employee whose name is on the service account has never seen a list of what acts in their name. Neither has the customer whose assistant holds their sessions.

What is actually wrong with OAuth scopes and API keys?

Both are fine primitives being asked to carry a load they were not designed for.

OAuth scopes are per application and semantically vague. A user clicks a consent screen that says the app would like to read and write your files. Which files? For how long? Can it delegate that to something else? The scope string does not say, because scope strings were built to be coarse. Worse, that grant lives in the resource server's database. It is not an artifact the user holds, so the user cannot show it to anyone, audit it, or hand it to an incident responder. Consent dashboards help, and every dashboard is one more island.

API keys carry ambient authority. A key is a bearer secret with no expiry, no stated scope beyond whatever the server decides it means, and no record of who issued it or why. Ambient authority is the technical term for authority that comes along for the ride: the key can do whatever the account can do, in whatever context it is used. This is why a single compromised credential turns into a very bad week. The npm worm sometimes called Shai-Hulud propagated through maintainer credentials precisely because a credential's reach was not bounded by anything, and reporting on that campaign described hundreds of packages affected across successive waves.

The Snowflake customer campaign of 2024 makes the same point from the other direction. Reporting from Mandiant and others put the number of affected customer tenants at roughly 165, and the mechanism was not an exploit against Snowflake but valid credentials, harvested by infostealers, still carrying authority nobody had enumerated. If you cannot list which credentials hold authority, you cannot tell which ones to turn off.

Read the last two columns. Everything above the final row is a private fact held by whoever issued it. Only the last row is portable evidence.

What would an authority graph actually be?

Here is the idea in one sentence, and then the mechanism slowly.

Every grant of authority is a signed object, each one an edge from the granter's key to the grantee's key, and the graph is simply the set of edges that are currently live.

The move that makes this work is small and consequential: stop recording authority as a row in a database somewhere and start recording it as a signed artifact that the granter, the grantee and any verifier can each hold a copy of. A database row is a claim by whoever owns the database. A signed object is a fact that anyone can check.

What is in an edge

In the delegation chains Manav ships today, a single edge carries these fields. They are worth walking through one at a time, because each one closes a specific failure you have probably lived through.

{
  "iss":            "pk_human_4a91...",     // the granter's key. For a root edge, a human.
  "delegateKey":    "pk_agent_77c2...",     // exactly who receives this authority
  "scope": {
    "actions":      ["tickets.read", "tickets.comment"],
    "resources":    ["queue:support-tier1"]
  },
  "constraints": {
    "max_per_day":  200,
    "requires_human_approval_above": null
  },
  "notBefore":      "2026-09-01T00:00:00Z",
  "notAfter":       "2026-12-01T00:00:00Z",  // authority that expires by default
  "maxChainDepth":  1,                        // this agent may NOT sub-delegate
  "revocationId":   "rev_01JB2K...",          // the handle that kills this subtree
  "sig":            "ed25519:..."             // signed by iss
}

delegateKey names the recipient precisely. Not "the ticketing app" as a category, but one specific public key. If someone copies this object and tries to use it from a different key, verification fails, because the object was issued to a key and the holder must prove possession of it. A bearer secret has no such property, which is why a leaked API key is game over and a leaked delegation is a piece of paper.

scope.actions is a list of verbs, not a category. The difference between "read and write your files" and an enumerated list of actions is the difference between a permission and a promise. The verifier can check membership of a list. It cannot check a vibe.

constraints is where the interesting policy lives: rate ceilings, value thresholds, an amount above which a fresh human signature is required. It turns the edge from a binary grant into a bounded one.

notBefore and notAfter make expiry the default rather than a chore. The reason old credentials accumulate is that nothing in the format forced them to end. Here, an edge without an end date is an edge that failed validation.

maxChainDepth is the field most people have never seen and immediately want. It states how many further hops of delegation are permitted beneath this edge. Set it to zero and this agent can act but cannot pass authority on. Set it to one and it may hand a bounded slice to a sub agent and no further. Multi agent systems fail in exactly this dimension, and almost nothing in production today bounds it. We go deeper on that in how delegation tokens work.

revocationId is the handle that lets the root kill this edge and, importantly, everything beneath it.

The graph is just the edges

Once every grant looks like that, the authority graph is not a new database you have to build and keep in sync. It is a view. Take the set of edges whose chain terminates at your key, discard the expired and the revoked, and render what remains. The human sees a tree: me, my three agents, the two sub agents one of them was permitted to spawn, and what each of them may do until when.

Manav renders the human's outgoing edges in the authorization inbox at /app/, which is also where actions requiring a fresh human signature queue up. To be clear about what is and is not shipped: the chains, the offline verification and that personal view exist today. A multi organisation administrative console and per organisation key rotation tooling are on the roadmap and are not something you can buy this afternoon.

How does a supplier verify one edge without calling you?

This is the property that changes the economics, so it is worth showing rather than asserting.

An agent presents a chain: a root edge signed by a human key, then zero or more sub delegations, then a signature over the specific action it wants to perform. The verifier walks it.

function verifyChain(chain, action, now, publishedRootKeys) {
  let expectedIssuer = chain[0].iss;

  if (!publishedRootKeys.has(expectedIssuer)) return DENY("unknown root");

  for (let i = 0; i < chain.length; i++) {
    const edge = chain[i];

    if (edge.iss !== expectedIssuer)            return DENY("chain break");
    if (!ed25519.verify(edge.sig, edge, edge.iss)) return DENY("bad signature");
    if (now < edge.notBefore || now > edge.notAfter) return DENY("expired");
    if (revoked(edge.revocationId))             return DENY("revoked");
    if (i > edge.maxChainDepth)                 return DENY("too deep");
    if (!subsetOf(chain[i].scope, edge.scope))  return DENY("scope escalation");

    expectedIssuer = edge.delegateKey;   // the grantee becomes the next granter
  }

  return actionInScope(action, chain[chain.length - 1].scope)
    ? ALLOW : DENY("action outside scope");
}

Notice what the verifier does not do. It does not call Manav. It does not call your identity provider. It does not maintain a session with anything. It checks signatures against published keys, checks two timestamps, checks a revocation list it can mirror, and checks that scope never widens as the chain descends.

That last check, the monotonic narrowing of scope, is the invariant that makes chains safe. Authority can only ever shrink as it is passed along. An agent cannot grant a sub agent more than it holds, because the verifier will reject the edge. This is an old and good idea, and readers who enjoy lineage will recognise its ancestors in SPKI and SDSI from the late 1990s, and its descendants in capability formats like UCAN. What is new is not the cryptography. It is having a human key at the root and a reason for suppliers to check.

Practically, this means your supplier's integration is a library call rather than a partnership. That is the difference between an authority model that works inside your tenant and one that works across the boundary where most of the interesting risk actually lives. We wrote the developer version of this argument in how do I prove an AI agent is authorized to act on my behalf.

What does revocation look like when authority is a graph?

Revocation is where the graph earns its keep, and also where I have to be careful not to oversell it.

The good part is genuine. Because every edge names its parent, revoking an edge invalidates everything descended from it, in one act, verifiable by everyone. You do not enumerate the sub agents. You do not chase tokens across four systems hoping you found them all. You publish one revocation, every verifier that mirrors the list stops accepting the subtree, and the authority is gone. An incident that used to be a Thursday afternoon of archaeology becomes a single signed statement.

Compare that with token sprawl, where revocation means finding every place a credential was copied, which you cannot do, because that was the original problem.

Now the honest part. Revoking a chain revokes authority that flowed through chains. It does not reach into a SaaS tenant and delete an OAuth grant that was issued independently by that tenant. It does not rotate an API key someone pasted into a config file. Those systems issued their own authority under their own model, and a signed revocation from your key means nothing to them unless they chose to check.

So the correct claim is bounded: within the chained portion of your authority, revocation is complete and instant. Outside it, you are back to the old world. The strategy that follows is not "adopt chains and you are done", it is "move your highest consequence grants into chains first, so that the part you can kill in one act is the part that can hurt you most." The mechanics of the kill path are in building the kill switch.

What does the EU AI Act require that opacity cannot deliver?

There is a compliance argument here and it is stronger than most compliance arguments, because it is about a capability rather than a document.

Article 14 of the EU AI Act requires that high risk AI systems be designed so that natural persons can effectively oversee them, including being able to understand the system's capacities and limitations and to intervene or interrupt operation. Read that with an authority lens and the requirement is sharp: a person who cannot state what a system is permitted to do cannot oversee it in any meaningful sense, and a person who cannot interrupt it across every system it touches cannot intervene.

An organisation whose answer to "what can this agent do" is a three day investigation does not have an oversight problem it can fix with training. It has one it can only fix with an artifact. A graph of signed edges is exactly the artifact: it states capacity in machine readable form, it is inspectable by the overseeing person, and its revocation is the intervention. Our implementation reading of Article 14 is in the Article 14 implementation playbook.

Honest limits

• The graph only shows authority that flowed through it. This is the big one. A personal access token an engineer created directly in a SaaS tenant is invisible to the graph, exactly as it is invisible to everything else. Chains make new authority legible. They do not retroactively find old authority. Pair the graph with scanning for coverage, and treat the two as complements rather than competitors.
• Adoption is two sided. An edge is only useful if a verifier checks it. Early on you will hold beautifully structured authority that nobody asks to see. Start where you control both ends, which is usually your own services and your own agents, and expand to suppliers as the format gets familiar.
• Revocation propagation stops at the chain boundary. Said above, worth repeating, because it is the claim most likely to be over read.
• A graph with three hundred edges is not self explaining. Rendering matters enormously. Grouping, sensible defaults, and a plain language summary are the difference between a control and a wall of JSON that nobody reads. This is a product problem and it is not solved by having the right data.
• The graph is sensitive. A complete map of what acts for a person is a valuable thing to steal. It has to be human held and selectively disclosed rather than pooled centrally, which constrains some obvious product designs, deliberately.
• Manav has not shipped an enterprise console. Chains, verification and the personal view are live. Multi organisation administration is roadmap. Anyone telling you otherwise is selling.

An open schema, not a product feature

The edge format above should not belong to a vendor, and we would rather it did not belong to us. The useful version of this is an open Agent Authority Inventory schema: a documented edge object, a validator anyone can run, and a conformance test suite, so that an authority graph from one implementation can be read by a verifier built against another.

The reason to want that, even from a commercial position, is that opacity is not a competitive advantage for anybody. A supplier that can check one edge without integrating with your identity provider is a supplier that can transact with everyone's agents. That is worth more than a proprietary format.

What to do this week

1. Ask the question out loud. In your next agent review, ask what else the agent can do and time how long the answer takes. Write the number down. It is your baseline and it will be uncomfortable.
2. Inventory the granters, not the grants. List every place in your organisation where someone can issue authority to a non human: the identity provider, each SaaS admin panel, the CI system, the gateway config, the personal token pages. The list is longer than you expect and it is the map of your opacity.
3. Find the edges with no expiry. Any grant without an end date is permanent until someone remembers. Sort by age and look at the top of the list. Set a default expiry for anything issued from now on.
4. Bound delegation depth explicitly. For every agent that can invoke another agent or tool, decide right now whether it may pass authority onward, and write that decision down somewhere a machine can read it. Most should be zero.
5. Pick your highest consequence grant and chain it first. Not the easiest one. The one where an incident is a headline. Move that grant to a signed edge with scope, expiry and a revocation handle, and confirm you can kill it in one act.
6. Give one human the personal view. Pick an employee with several agents and show them everything acting in their name. The reaction to that screen is the most reliable business case you will find, and it takes an afternoon.
7. Write the one hour revocation playbook. Document exactly how you would remove all authority from one agent, across every system, and then rehearse it. If the rehearsal takes longer than an hour, you have found your priority.

If you want to see chains rather than read about them, the agent delegation demo issues one and verifies it in the browser, and the integration docs cover the chain endpoints and the verification library.

Frequently asked questions

How can I see everything an AI agent is allowed to do on my behalf? Only if every grant is a signed edge from your own key. An authority graph rooted in the human collects those edges, shows scope, expiry and delegation depth for each, lets any service verify a single edge without calling the issuer, and lets you revoke a whole subtree in one act. If your grants live only as rows in other people's databases, no complete view is possible.

What is an authority graph? The set of currently live, signed delegations rooted in a human key. Each edge names the granter, the grantee's key, the permitted actions, constraints, a validity window, a maximum further delegation depth, and a revocation handle. The graph is a view over those edges rather than a separate system of record.

What is Authority Opacity? The condition where authority is real and being exercised but cannot be enumerated by its owner, inspected by the human it acts for, or verified by anyone other than the system that issued it. It is distinct from sprawl, which is having too much authority. Opacity is not being able to see what you have.

Do non-human identity tools already solve this? They help and they do not close it. Inventories are reconstructions built by scanning systems you have credentials for, so they miss authority held elsewhere. They report what exists rather than who authorized it under what scope. And their output is a private dashboard, which no third party can verify.

How do you revoke an agent's authority everywhere at once? Within chained authority, publish a signed revocation of the edge and every verifier that mirrors the revocation list stops accepting that edge and everything descended from it. Outside chained authority, in tokens and grants issued independently by other systems, you still have to go and turn each one off.

Could Microsoft or Okta just build this? They can and probably will build tenant scoped versions, and those will be useful. What a tenant bound graph cannot include is authority granted outside that tenant, which is where agents increasingly operate, and it cannot give a supplier a way to verify one edge offline without joining your identity provider. Rooting the graph in the human rather than the tenant is what makes it cross boundary.

Does this require a blockchain? No. Edges are signed objects verified against published keys, and revocation lists are ordinary mirrored data. A public ledger could publish revocations, which is a real if modest benefit, but it cannot establish that a particular key belongs to a particular human, which is the part the model actually depends on.

Sources

1. Regulation (EU) 2024/1689, the EU Artificial Intelligence Act, Article 14 on human oversight: eur-lex.europa.eu
2. Mandiant and Google Cloud reporting on the 2024 campaign targeting Snowflake customer instances, including the approximate count of affected customer tenants: cloud.google.com threat intelligence
3. Reporting and vendor analysis on the self replicating npm supply chain worm known as Shai-Hulud and its propagation through maintainer credentials: securelist.com
4. OAuth 2.0 Authorization Framework, RFC 6749, and Token Introspection, RFC 7662: rfc-editor.org
5. OAuth 2.0 Rich Authorization Requests, RFC 9396, on structured authorization detail beyond scope strings: rfc-editor.org
6. SPKI certificate theory, RFC 2693, the historical precedent for delegation with bounded scope and depth: rfc-editor.org
7. Coinbase disclosure regarding the 2025 support contractor incident and its estimated remediation cost range, as filed with the SEC and reported at the time: SEC EDGAR full text search
8. Vendor inventories of machine and non human identity from providers including Astrix, Oasis, Entro and Veza, source of widely repeated machine to human identity ratios that vary by methodology.

An agent you cannot enumerate is an agent you cannot oversee, and an agent you cannot oversee is not delegated authority. It is a rumour with an API key.