I’ll give you my house keys if your agent security stack can actually do provenance – a hashed chain of events that can track agents and sub-agents to an originating user, and determine whether their actions were compliant with the user’s intent.
I’m only this confident because I know your agent stack is less homogeneous than you think. You surely know how Claude Code, Cowork, Bedrock are different and need their own security policies. But AI adoption in enterprises is happening ad-hoc, so your stack will likely include stuff like LangChain, Crew, Cursor, ServiceNow, Snowflake, n8n, Lovable, Salesforce, Cohere, Claude Managed Agents, AgentCore, Cloudflare.
All these products have a different take on observability, security, and identity. This means that policies are not portable across products. You may build on Gemini Enterprise Agent Platform with their SPIFFE-attested agent identities, full traces, and built-in gateway with LLM-based intent analysis, but if somebody then decides to run OpenClaw or an equivalent, all of that goes out the window.
This is why nearly all agent security products will sell you discovery and observability. And they’re right! You can’t really enforce any kind of policies without that baseline knowledge of agents and models.
Alongside observability, agent identity puts a name to an otherwise anonymous and ephemeral workload. After two years of the industry figuring out agents, we landed on both identity and observability as the baseline for the security and governance layer. Between them, we can keep track of agents, detect when agents are being malicious or dumb, prevent them from being malicious or dumb, and refine policies.
But implementations vary widely. I usually say that any observability and/or security is better than none, so you’ll surely see benefits regardless. But if you really want to evaluate the quality of your identity and observability implementation, you can use provenance as a stress test.
Environment-wide provenance is a difficult endeavour. It has an extensive set of prerequisites which include the following:
- An immutable, contextualized chain of events
- Tying events with blended human-agent identities
- Enforcing security policies at runtime
- Conduct remediation based on intent
Let’s see how this would look, starting the mechanism for establishing ground truth.
An immutable, enriched chain of events
Compared to a trace, which captures how a request traverses across the stack in a linear manner, a chain of events describes the full arc of an agentic workflow: the agent executions, the LLM calls, the tool invocations, subagent spawns, and the retries.
Conceptually, you can categorize agent actions into two – model activities and system changes.
- Model – the content produced by the LLM which includes prompts, tool calls, orchestration (invoke agent, invoke workflow, create agent), and the retrieval and embedding steps around them. There’s also the associated metadata, such as for how long it ran, how many traces it spanned, how many LLM calls it made, how many tool calls, how many failed, and how many tokens it spent across input and output. These are ephemeral and not logged unless explicitly configured so.
- System – these consist of tangible events or changes in your environment. They include the operation that was called and the corresponding service or endpoint. Traditional logging already has these actions stamped with a time, marked as success or error, and contains data such as IP addresses, request IDs, session context.
Regardless of the approach, the logs must survive non-deterministic actions. You can’t reproduce a session by replaying the prompt, so the record has to capture what happened the first time.
A durable log lets you ask questions of the past. With the right metadata, you can reconstruct a session end-to-end. You can replay a session the way it actually unfolded to see what actions were taken, when, by whom, and from where.
LLM-produced content and actions are not natively coupled together. The agent’s reasoning needs to be bound to the actions it took such that a tool invocation isn’t an orphan, but rather the visible consequence of something the model decided.
To graduate logs to a chain of events, you can do the following:
- A minimum viable chain has a timestamp for every event to determine a chronological order of actions. In sequential workflows this works well, but as soon as you get into parallelization, the timestamp loses its resolution.
- An immutable, append-only file write. These logs are tracked and stored independently from an LLM and contain all the system changes.
- A hash chain, where every action in a sequence is cryptographically tied to the previous and following ones.
When it comes to provenance, we want this chain of events to trail the activity taken within a privileged session, recorded at the level of individual calls. Each entry names the operation that was called that can include an identity check, a describe-and-read against a resource, or a change to a policy. It also needs the called resource, which can be the service or endpoint on the other end.
It carries a timestamp, giving the entry a place in the sequence, and an error indicator, so you can separate what was attempted from what actually succeeded and filter down to the calls that went through.
But it also needs to record the user identity behind the call and the user agent that carried it, so you know both who acted and what tool they acted through.
Tying events with blended human-agent identities
Chained events give you confidence when tracking an agent, but the point of provenance is to determine how they compare against security and governance policies. There’s a lot of nuance here as your policies are no longer simplistic IP allowlists. It depends on who wrote the agent, who ran the agent, and what the agent was written for. These are all identity qualities, across users, devs, and workloads.
The complication is that the initiating identity isn’t always a person. What kicked off an action might be a user, but it might just as easily be a developer whose permissions the agent inherited, a service account the workflow runs under, a workload that spun the agent up, or another agent entirely. Each type of identity carries a different scope and a different claim to authority, and each has to resolve to something accountable. A service account that can reach a database says nothing about whether the human behind it should. Correlation can’t stop at the nearest identity. It has to keep resolving until it reaches the original scope and the intent that authorized the action in the first place.
Provenance from an agent’s action back to a person only works if the person’s and the agent’s identities are part of the same request. Static API keys can’t be scoped per agent and can’t be revoked without rotating the key for everyone who holds it. VPN-based access puts the agent on the network but can’t tell an agent apart from the user driving it. The built-in auth natively available with each AI vendor is provider-specific, so it’s not portable across platforms.
To correlate an agent’s identity with a human’s – a blended identity – you first need to treat an AI agent as a workload identity, with the same attestation, policy, and audit you’d apply to any other workload. Following that, you need to verify the human and the agent separately, then bind the two together cryptographically, so every action ties back to a named person, a specific agent, and the policy that governed it.
This now allows a more sophisticated take, namely by answering “did this agent, acting for this user, reach further than it should have”?
The cryptographical binding process can be performed by an identity gateway. It can federate with an existing identity provider to verify the user, and issue each agent client its own credentials. Then, on each session, it can produce a signed token that binds the user and the agent into a single verifiable pair. That token travels with every tool call the agent makes. The agent never receives the credentials to the upstream system itself.
Leveraging an IAM integration with upstream services such as Postgres or Kubernetes can implement enforcement of that service via a session-bound temporary user, role, or policy. This way, the service itself controls and enforces the agent’s effective entitlements.
The net effect is that every access decision is made against the combination of the user’s identity and the agent’s workload identity and it’s made with short-lived tokens issued against your policies rather than long-lived secrets scattered across agents.
An action taken by a sub-agent traces to the agent that invoked it, which traces to the workload that launched that one, which traces, eventually, to a human request. So the correlation has to survive handoffs: each link preserving the identity and the scope of the one before it, all the way down, so the blended identity stays intact from the last tool call back to the first prompt.
Security policies at runtime
Policy is where the blended identity principle becomes enforcement. When an agent requests access, the request is evaluated against your access policies the same way a human request is, but matched by a dedicated agentic requestor type, one that recognizes there are two parties on the request, not one.
A policy is built on top of the following components:
- The agent itself, defined by its agent identity: An agent identity can be something as simple as a label that offers a persistent identifier of an otherwise ephemeral workload. On the more complex end, identities can be defined based on a standard, verifiable format such as a workload-identity standard like SPIFFE, so the agent named in the policy is a cryptographically attestable principal rather than a label anyone could assert.
- The resource, i.e. the thing the policy grants or denies access on: a specific tool server, another agent, or an endpoint, which has to be registered before it can appear in a policy. Where registries are regionalized, a policy reaches only the resources in its own region.
- The agent’s role: what the agent is actually permitted to do with the resource, typically a narrowly scoped grant that authorizes reaching the service and nothing more.
- The condition: an extra constraint that further restricts what the agent can access, which contains explicit attributes such as name of tool or MCP operation.
- The business context: agents need to inherit or have awareness of the user’s role, scope, and permissions within the wider organization. An agent operating on the behalf of an on-call engineer versus the same agent accessing specific account data for a customer experience representative needs to behave differently as part of the triggering user.
With a policy defined, agents can only perform the action explicitly allowed. But across your stack identity and security policies live in separate places: identity services, resource and service control policies, cloud access logs, etc. Across policies defined through federation, through group membership, through cross-account roles, an identity may reach a resource it was never directly granted. These are effective policies, which describe how all parent and ancestor policies in the resource hierarchy are inherited for a resource.
This means that an agent may perform actions that weren’t accounted for which don’t explicitly violate the policies. In this instance, policies also act as the point of remediation.
Remediations and intent
When talking about agent policies, remediation and intent are two sides of the same coin. You need to determine how the agent interpreted (or misinterpreted) the original intent and misbehaved. For example, you may have prompted it ‘don’t delete databases’ and blocked rm -rf at the shell, but the agent wrote a Python cleanup script. It respected the guardrail but violated the intent.
With provenance, you don’t just tie the agent back to the originator, but once you reach it (the human-agent blend), you can see the scope and intent that set off the chain of events.
You can finally ask the question the whole chain exists to answer. Was the action compliant with the intent of the person who originated it?
That’s the difference between telemetry and provenance. While telemetry tells you an agent made a call, provenance tells you which human’s intent that call was serving, which agent carried it, and which policy was enforced.
As such, you can issue corrective policy changes after the fact. When you discover an overly permissive policy after an agent performed its actions, the provenance can pinpoint both the cause and actor and tell you precisely what to change and for whom. A shorthand policy improvement typically swaps the permissive policy for a least-privileged one, scoped to that identity.
You also have a preventive option, which enforces restrictions before the events happen. This is where identity-aware policy at a gateway comes in. Instead of allowing an agent to act based on static policies, the gateway can enforce a least-privilege permission by issuing the scoped token for the agent’s access token on every request.
P0’s hard work on their provenance slice
Provenance really is ambitious. I had to dust off my engineering cap to put this together, and I haven’t seen an end-to-end commercial solution on the market. You’ll probably hear vendors claiming they solved it, but they only figured out part of the problem at best. The guys at P0 have figured out some of the hard parts.
Their piece in the provenance spiel is their implementation of blended identity and runtime policy enforcement. If an agent operates via a service account, a cloud log would show that something ran, but there’s no native way of seeing who asked it to do so or whether they had the right to. P0 verifies the originator and the agent separately, then binds both into a single session token. It federates with Okta, Entra ID, or any OIDC-compatible IdP and it re-evaluates those IdP claims on every tool call, not just at login, so effective access always reflects the user’s current entitlements. Each agent client registers with the OAuth server and gets a signed, session-scoped token that never carries upstream credentials. Every action then ties back to a named human, a specific agent, and the policy that governed it.
I called out agent discovery as the main security offering for agents, which is fine, but everybody does agent discovery. Not too many map permissions. Knowing an agent exists tells you nothing about what it can actually reach once you account for federation, group membership, and inherited roles across every platform in your stack. P0 maps that effective policy across providers, which is exactly the baseline you need before provenance is even on the table.
On the chain of events itself, P0’s session recording shows you both how far they’ve gotten and where the hard part still lives. For AWS, it ties a JIT session to the AWS CloudTrail activity underneath it, namely event names, source services, identities, timestamps, request IDs, success or failure. It retains them as a queryable log you can replay after the fact. That’s the durable record that survives non-deterministic sessions, which is more than most vendors give you. It doesn’t go as far as the LLM context-enriched hash chains, but by now I’m sure you understand how ambitious the whole thing is.