At 2:14 a.m., a production database table gets truncated. The audit log shows the actor was svc-ops-agent, a service account with broad write access. That's all it shows.
Was the agent following a user's instruction, or a scheduled task? Did someone approve it? Did another agent hand it the job? Did a support ticket contain instructions the agent took as a command? Which model version was running, with which tools? Nobody can say, because the logs recorded what happened but not why it was allowed to happen.
This is the operational lineage problem. As organizations move agents from demos into workflows that touch real systems, it's becoming one of the most important and least solved problems in identity and security.
What operational lineage actually means
Data lineage traces where a piece of data came from and how it changed. Operational lineage does the same for actions. It is the verifiable chain that connects a human's intent to an agent's action, including every hop in between.
For any action an agent takes, you should be able to answer five questions with evidence rather than guesswork:
- 1.Who initiated it? The human, system, or schedule at the root of the chain.
- 2.Which agent acted? A specific, identifiable agent with a known owner, version, and configuration, not a shared credential.
- 3.Under what authority? The permissions delegated to the agent for this task, where they came from, and whether they were in scope.
- 4.Through what path? Every agent, tool, and service the request passed through, especially when agents call other agents.
- 5.What did it touch and produce? The resources read, the changes made, and the outcome.
If any link in that chain is missing, you don't have lineage. You have a log entry and a hunch.
Why this matters now
Traditional software is deterministic. If a script deletes a table, you read the script. Agents are different in three ways that break our existing accountability models.
First, agents decide at runtime. The same agent with the same permissions might do very different things depending on its prompt, context, and whatever content it reads along the way. Permissions alone no longer describe behavior, so you need a record of what the agent was asked to do and on whose behalf.
Second, agents act on behalf of others. When an agent uses a shared API key or a broadly privileged service account, it erases the distinction between "the agent did this" and "a user asked the agent to do this." That's the classic confused deputy problem, now at scale. A user with read-only access asks an agent with write access to "clean up" some records, and the agent obliges. Without lineage, you can't tell whether that was a legitimate request, a privilege escalation, or a prompt injection hidden in a document the agent summarized.
Third, agents chain. A planning agent delegates to a research agent, which calls a coding agent, which triggers a deployment tool. Each hop is a place where authority can silently widen and context can silently disappear. By the time an action lands, the original human is often four systems away and invisible.
The consequences are concrete. Incident response slows to a crawl when every investigation starts with reconstructing what happened from scattered logs. Auditors and regulators increasingly expect systems that act without a human at the keyboard to be traceable; the EU AI Act, for example, includes record-keeping obligations for high-risk systems. And customers deploying agents inside their own environments want proof, not promises, that those agents stayed within bounds.
How to prove operational lineage
Proving lineage isn't a single feature. It's a set of design decisions that together make every agent action attributable, scoped, and verifiable.
1. Give every agent a first-class identity
Start by retiring shared credentials. Each agent should have its own identity, registered like any other principal, with a named human or team owner, a declared purpose, and metadata describing what it actually is: the model and version, the tool set, and a hash of its configuration or system prompt. When an agent's behavior changes because someone updated its prompt or swapped its model, its identity record should reflect that. "The agent" isn't meaningful for forensics. "Agent invoice-reconciler, v3.2, owned by Finance Ops, config hash a91f…" is.
2. Use delegation, not impersonation
When an agent acts for a user, it shouldn't simply become that user, and it shouldn't use its own standing privileges either. It should hold a delegated credential that carries both identities: the user as the subject and the agent as the actor. OAuth 2.0 Token Exchange (RFC 8693) already supports this pattern through its act claim, which can nest to represent multi-hop delegation chains. One caveat the spec is explicit about: those nested prior-actor claims are informational, not something a resource server should make access decisions on. The authorization server assembles the chain without proof from each delegating agent. So the token tells you the chain is claimed; the tamper-evidence layer below is what lets you prove it.
Delegated credentials should be short-lived and scoped to the task. An agent asked to draft a reply to one customer email doesn't need access to the entire mailbox for the rest of the day. Narrow scope limits blast radius, and it also makes lineage legible: the credential itself documents what authority was granted, by whom, and for what.
A good rule of thumb is that effective permissions should be the intersection of what the user can do and what the agent is allowed to do, never the union.
3. Propagate lineage context across every hop
Lineage breaks the moment one system fails to pass context to the next. Every request an agent makes, whether to a tool, an API, or another agent, should carry a lineage context: a correlation ID tying the whole chain together, the originating principal, and the delegation chain so far. Standards like W3C Trace Context give you a proven transport for correlation; your delegation tokens carry the authority.
The key discipline is that downstream systems must enforce this context, not just log it. A tool that receives a request without valid lineage context should refuse it. Otherwise, lineage becomes optional, and optional controls are the first thing skipped under deadline pressure.
4. Log at decision points with structured events
Agent logs tend to be either too sparse ("tool called") or too noisy (full transcripts dumped into a bucket). What you want are structured events emitted at meaningful decision points: when a task is assigned, when authority is delegated, when a tool is invoked, when a resource is modified, when a human approves or rejects something.
Use a consistent naming taxonomy so events are queryable across systems, something like agent.delegation.granted or resource.record.deleted. Each event should record the actor, the principal it acted on behalf of, the authority it held, references to its inputs, and the outcome. Store references to sensitive inputs rather than the raw content where you can, so your audit trail doesn't become its own data exposure risk.
5. Record intent and approvals as evidence
For consequential actions, the most important link in the chain is often the human one. When an agent pauses for approval before sending a payment or modifying production, the approval itself should be a first-class, signed event: who approved, what exactly they were shown, and when. "A human was in the loop" is only meaningful if you can prove which human, and what they agreed to.
6. Make the record tamper-evident
A lineage trail that can be edited after the fact proves nothing. Write lineage events to append-only storage, separate from the systems the agents operate on, so a compromised agent can't cover its tracks. Techniques like hash-chaining events or signing them at emission time let you demonstrate that the record hasn't been altered, which matters enormously when the audience is an auditor or a court rather than your own team.
7. Test your proof
The final step is the one most teams skip. Pick a random agent action from last week and try to answer the five questions: who initiated it, which agent acted, under what authority, through what path, and with what effect. Time how long it takes. If the answer requires three engineers, four dashboards, and an afternoon, your lineage exists in theory only.
Run these drills regularly, and treat any gap as a bug. Lineage that isn't exercised decays quietly, one unpropagated header at a time.
Lineage is how agents earn trust
It's tempting to treat all of this as compliance overhead, the tax you pay before agents can do interesting work. The better framing is the opposite. Operational lineage is what makes it safe to give agents more autonomy. When every action is attributable, scoped, and verifiable, you can grant broader capabilities with confidence, investigate incidents in minutes instead of days, and show customers and regulators exactly what your agents did and why.
Back to that 2:14 a.m. truncation. With lineage in place, the answer is one query away: a scheduled cleanup job, delegated by the data platform team's on-call engineer, executed by db-maintenance-agent v1.8 with a token that should have been scoped to staging but was incorrectly minted with production scope. That's not a mystery. That's a fixable bug with an owner.
The question for every organization deploying agents isn't whether something will eventually go wrong. It's whether, when it does, you'll be able to prove what happened.
Why NewCore does this well
Most identity platforms were built for humans and extended to agents as an afterthought. The result is agents that hold copied credentials, sit behind a flat "sponsor" field, and keep running long after the person who created them has moved on. NewCore takes a different approach: agent lineage is part of how the identity itself is modeled, not something reconstructed from logs.
Every agent has a human anchor. Each agent is registered once and gets a NewCore identity tied to an accountable human. NewCore separates two relationships that other products blur. A Personal Agent has an Owner whose authority it acts on. An Autonomous Agent has a Sponsor who is accountable for it but whose access it never inherits. That distinction answers "who initiated this, and under whose authority" at the identity layer, before a single action is taken.
Authority is derived, not copied. A Personal Agent's effective authority is the intersection of its owner's current access and the agent's Tool Pack, evaluated at the moment of use. Nothing is copied into a standing grant that can drift. When the owner changes roles, the agent's authority changes with them. When the owner goes on leave, the agent is suspended. When the owner leaves the company, the agent is terminated and its sessions are revoked, and no override can keep it alive. If an Autonomous Agent's sponsor becomes ineligible, NewCore resolves a replacement or raises an explicit sponsorship gap. Nothing falls through silently.
One sanctioned path to credentials. Instead of agents running on shared API keys or personal access tokens, NewCore mints real, scoped, short-lived tokens for each agent against the target SaaS. A request outside an agent's granted scope is refused, and the refusal is recorded. NewCore stays in the control plane rather than proxying traffic, and it continuously discovers tokens created outside that path so admins can see and revoke them. Revoking an agent revokes its tokens at every connected SaaS.
Evidence that is verified, not assumed. NewCore correlates its own mint and policy events with the target system's audit log, so the record shows both what NewCore authorized and what the SaaS confirms actually happened. Events follow a consistent resource.subresource.verb taxonomy and carry the actor, the principal, the configuration version, and the outcome. Lifecycle executions cannot report Complete while any effect is still unverified. A step that ran and a change that landed are treated as different claims, because they are.
Provenance for every value. When an auditor asks why an agent has the access it has, NewCore can trace each resolved value back to the specific rule and scope that produced it. The answer comes from the same resolver that runs in production, so what you inspect is what actually executes.
Put together, this is operational lineage by design. The five questions from earlier in this post are answered by the identity model itself, not by a forensic exercise after the fact. That is what lets organizations give agents real work to do and still stand behind every action they take.