Know It. Control It. Prove It.

A call to action for AI providers, from the identity side of the industry

The frontier AI labs are getting very good at explaining what went wrong.

OpenAI's Hugging Face postmortem describes agents bypassing isolation controls, acquiring credentials, and compromising real systems during internal cybersecurity evaluations. Anthropic's September 9 assessment describes four incidents involving unauthorized access to third-party systems. Its investigation eventually expanded to screening roughly 481 million transcripts, with 9.2 million escalated for model-assisted review.

The transparency matters. So does the research into why a model kept going, what it understood, and whether its reasoning can be trusted.

But there is another set of questions that should not require a research project.

What can this agent actually reach? Who authorized that access? What has it done with it? And can I take that authority away, right now?

I'm writing this as the co-founder of YeshID, an identity and access management company. Those are the questions I want answered before an agent gets access to a business. Not in the postmortem.

We should absolutely build models that make better decisions. We should also stop treating better judgment as a substitute for enforced boundaries.

Alignment cannot be the security boundary.

A model can misunderstand its task. The system accepting its credentials should not have to share the misunderstanding.

We were already behind

The Cloud Security Alliance's January 2026 survey found that only 12% of respondents were highly confident their organizations could prevent attacks through non-human identities. Fewer than a quarter reported documented, formally adopted policies for creating or removing AI identities. More than 16% said they did not track the creation of new AI-related identities at all.

Read that last one again. Some organizations are not struggling to govern the access they know about. They are not recording the identities being created in the first place.

Now put autonomous software on top of that.

The identity industry does not get to pretend we had this solved before agents arrived. We didn't. The same CSA report describes unclear ownership, credential sprawl, manual processes, and slow remediation. Agents are arriving on top of that debt, not replacing it with a clean system.

That is why "we gave the agent a service account" is not a satisfactory answer.

It tells me how something can log in. It does not tell me whether anyone is governing what happens next.

The task is small. The authority might not be.

Picture a sales manager asking an agent to prepare a renewal brief for one customer.

The agent reads the customer's CRM record, retrieves the contract, and delegates an analysis to another agent. That second agent uses a connector to pull supporting data. Somewhere in the chain, a broad integration credential makes considerably more information available than the original task required.

The brief is finished. The manager closes the conversation.

What, exactly, ended?

The task? The parent agent? The delegated work? The credentials issued along the way? The ability to obtain another token tomorrow?

In a poorly governed setup, those are different answers.

Nothing about "prepare a renewal brief" authorizes changing the customer's contract, exporting the entire customer database, or leaving a reusable access path behind. But a valid credential can make those actions technically available anyway.

That is the problem. The business authorized a task. The systems may have granted something much larger.

And the agent's authority does not have to stay where it started. Access can be requested and expanded during execution; MCP's authorization specification, for example, explicitly supports obtaining additional scopes through a new authorization flow when existing permissions are insufficient, as described in the Model Context Protocol specification.

This is why the unit of control cannot just be the API key.

The agent is the actor. Its credentials are how it exercises authority. The task explains why that authority was granted. Delegation explains how it moved.

We need to keep those connected while the work happens.

Know it: follow the authority, not just the account

A security team should be able to ask, "Show me every agent that can reach our customer data," and get an answer it can act on.

Not a list of integration names. Not a spreadsheet someone last updated before the pilot went live.

For each agent, the answer should include its identity, its accountable human owner, the task it is performing, the systems it can reach, the access it currently holds, and when that access ends.

It should also answer a question that an owner field cannot:

Whose authority is this particular agent exercising?

The person responsible for maintaining an agent is not necessarily the person who authorized today's task. An agent maintained by IT might be acting for a sales manager, through another agent, using access granted by a third system. Naming someone in IT does not explain that chain.

Every handoff should preserve who initiated the work, what was delegated, and what permissions went with it. If an agent acquires additional access, that should become visible as it happens. If it creates a child agent, the child should not become an unexplained new entry in someone else's logs.

Purpose matters here, but a free-text field saying "help sales" is not a control. Preparing a renewal brief should translate into a concrete boundary: these customer records, these operations, these permitted destinations, for this task.

The agent should not get to rewrite that boundary by producing a persuasive explanation of why more access would be helpful.

Ownership needs an actual lifecycle, too. When the accountable person leaves, transfer responsibility explicitly or suspend the agent. Do not let the account remain active while everyone assumes someone else inherited it.

And expose all of this through an API. A registry that only the provider can query is internal tooling, not customer control.

Control it: the boundary must work even when the agent gets it wrong

The test of an access control is not whether a cooperative agent follows it. The test is whether the boundary holds when the agent tries something it should not.

That means enforcement outside the model.

The renewal agent should receive the access needed to prepare the brief. Changing a contract should require different authority. Exporting unrelated customer records should be denied. Delegating a task should not silently become a way to expand permissions.

No amount of confident reasoning should turn "I need this to finish" into authorization.

Privileged access should be just-in-time, narrowly scoped, and short-lived by default. Authority granted for a task should end with the task. An agent should not accumulate permanent privileges simply because it completed a series of temporary jobs.

Authorization also needs to remain current. Passing a check at the beginning of a session is not a permanent entitlement to everything that follows. Each protected action should be checked against the authority and policy valid at that point.

Then there is the stop button.

Stopping the conversation is not the same as stopping the access.

Customers need to terminate a task's authority, including the credentials and delegated access issued from it. They need to do that through their own security systems, automatically when appropriate, without opening a support ticket or asking the agent to cooperate.

And revocation needs an honest clock.

OAuth's revocation standard explicitly recognizes propagation delays and the difficulty of immediately invalidating self-contained tokens at downstream systems. A successful revocation response is not, by itself, proof that every relevant resource has stopped accepting the authority.

So publish the time to enforcement.

If your API says "revoked" while the credential still works against a connected system, the job is not finished. Measure how long it takes for access to stop working, not how quickly the dashboard changes color.

An out-of-scope action should be denied before it executes. When existing authority needs to be withdrawn, that withdrawal should propagate in minutes, not become tomorrow's ticket.

Prove it: record what the systems did, not just what the agent said

After an incident, I do not want an agent's summary of its own behavior to be the primary evidence.

I want the record from the systems that authorized and performed the actions.

For the renewal example, that record should say something like: this agent, acting for this sales manager, under this task, used this delegated grant to request these customer records. This policy allowed the read. The resource returned the data. A later attempt to modify the contract was denied.

That is useful evidence.

It connects the actor, the authority, the decision, and the result. It also lets a security team distinguish between two very different failures: the agent bypassed a restriction, or the policy allowed something the business never intended.

Those require different fixes. A tool-call transcript alone does not settle the question.

Record successful and denied access. Record changes in authority. Preserve the connection between parent agents, child agents, tools, and downstream resources. Use identifiers that survive the handoffs so customers can correlate the events instead of guessing which entries belong together.

The evidence should be tamper-evident, retained outside the agent's control, and exportable. Customers need both a live event stream and a queryable history. An investigation should not depend on persuading a vendor to assemble a custom report.

Providers should also make the limits of their visibility explicit. A brokered tool call is not automatically proof of everything the downstream application did. Carry the context to that application and connect its evidence back to the task.

That is how you move from "the agent called a tool" to "we can account for the access."

The pieces exist. Ship the connection.

There is already real movement here. Microsoft Entra supports agent identities, human sponsors, lifecycle management, and access governance. MCP's authorization specification requires clients to identify the intended resource and servers to validate that the tokens presented were issued for them. These are useful building blocks.

The test, though, is not whether a vendor can point to an identity feature, an authorization feature, and a logging feature.

The test is whether a customer can follow one piece of work across all three.

Who is acting? Where did its authority come from? What can it do now? What did it attempt? What happened when we withdrew permission?

AI providers do not own every downstream application. Fine. They should control the access they broker, preserve identity and delegation across the handoffs they create, and expose the interfaces customers need to govern the rest.

Nobody is asking a model company to become every customer's identity provider. We are asking the companies shipping agent runtimes to make those runtimes governable.

Companies like YeshID should be able to connect organizational ownership, access policy, and lifecycle decisions to the authority those agents actually use. We should not have to reverse-engineer it from a chat history and an activity feed.

And my side of the industry has work to do, too. An agent inventory with a quarterly review attached is not enough. If authority changes during execution, governance has to reach into execution.

The handoff between the agent platform and the enterprise security system cannot be where accountability disappears.

The ask, directly

To the teams building and shipping agents:

1. Publish a queryable identity and authority record. Expose the agent, its accountable owner, the initiating and delegating principals, its task, its current grants, intended resources, and expiration. Preserve the chain when work moves to another agent or tool.
2. Make limited authority the default. Privileged access should be task-scoped, short-lived, and granted when needed. Evaluate authorization at each protected action. Expanding a task must not silently expand its permissions.
3. Ship API-triggered revocation with a published time-to-enforcement commitment. Let customers terminate a task's authority and its delegated grants. Report where enforcement has completed and where it has not. "Request accepted" is not the outcome.
4. Stream the evidence and preserve the history. Emit identity-aware authorization and action events, including denials, results, and changes in access. Make the record tamper-evident, correlated across handoffs, and exportable to the customer's own security tooling.
5. Make these controls usable outside your product. Support customer policy, security automation, and incident response through documented interfaces. A control that only your support team can operate is not a control the customer owns.
6. Put a date on it. Publish delivery commitments for the missing capabilities. A roadmap slide does not revoke a credential.

This is not a request to slow agents down. It is a request to make their autonomy something an enterprise can authorize without surrendering control.

I do not want security teams choosing between a useful agent with unbounded access and a harmless agent that cannot do its job. I want them to grant the right authority, let the work happen, and know that the boundary will hold when the agent makes a bad decision.

We do not need to settle what a model believes before deciding what it is allowed to do.

Know it. Control it. Prove it. Before the next postmortem.