The Attribution Graph Is Only as Good as Its Evidence

An agent did something. Who gets the page?

Picture an ordinary setup. An internal AI agent helps engineers ship changes: it reads a Slack request, calls an LLM to plan the work, and acts on GitHub through an MCP server. To let it talk to GitHub, someone created a classic Personal Access Token with repo and read:org scope and dropped it in the agent’s config.

One morning the agent opens a pull request that deletes a production workflow file. It is caught in review, no harm done. But someone asks the obvious question: who did this?

GitHub’s audit log says the action was performed by alice, because Alice created the PAT months ago. Alice was asleep. The agent did it, on a Slack request, planned by an LLM call, through an MCP server several agents share. GitHub sees none of that; from its side, Alice pushed a branch and opened a PR. That is the entire evidence trail the platform gives you.

The action was authorized. It was logged. And the log names the wrong actor. Every downstream decision, who to notify, what to revoke, whether to block, now rests on evidence that is technically accurate and practically useless.

The graph is easy. The evidence is the product.

At the marketing layer, almost everyone claims identity attribution for AI workloads, and the graphs look about the same: a user, an agent, a tool or database. The difference is underneath. Each edge was populated from some source of evidence, and those sources are not equal. An edge from a live parse of the network payload is a different claim than one inferred from a config file, a naming convention, or a control-plane log that arrived ten minutes late. They render identically while carrying very different confidence.

That is the whole argument: attribution is only as trustworthy as the telemetry it is built from. Containment (revoking a credential, scoping a permission, blocking an egress path) only works if you can attribute behavior precisely enough to touch the right thing without breaking the wrong thing. In the PAT story, weak evidence leaves two bad options: do nothing, or disable Alice. So the useful question about any attribution feature is what each edge is made of, and whether you would bet a containment action on it.

What weak evidence looks like

Most products that claim agent attribution build a similar-looking graph. The difference is what the edges are made of. These are the common low-grade sources, each producing a plausible graph but not strong enough, on its own, for a containment action.

• Static config, naming, and posture inference. Reading manifests, Terraform, pod names, labels, or CSPM and permission scans to infer what an agent can reach. It describes what is declared or allowed at a point in time, never what ran, and breaks the moment two agents share a deployment or a config drifts.
• Agent-framework self-reporting. The agent, its SDK, or the orchestration framework emits its own trace. Only as honest as the agent, only covers instrumented frameworks, and goes dark when the agent is misconfigured or compromised, which is when you need it most.
• LLM or egress gateway logs. A proxy in front of model and tool traffic sees only what routes through it. An agent that calls an API directly is invisible, and the logs usually carry a source IP rather than a workload identity.
• Control-plane audit logs alone. CloudTrail, GitHub audit, provider logs. They name the credential’s principal (the PAT owner), cover the control plane only, and arrive delayed. This is the exact failure in the PAT story: accurate, still pointing at the wrong actor.
• Flow and DNS logs. Who connected to whom at the IP or hostname level. No payload, no method, no credential, no data class. You learn the agent reached github.com, not what it did there.

The tell is the same: they describe what was possible, declared, or self-reported, not what was directly observed. Any of them can draw a graph; none lets you revoke the right credential with confidence.

What high-grade evidence looks like

High-grade evidence has one property the sources above lack: it is a direct observation or an authoritative binding. Below are the sources that produce it, and the grade each carries. The question stays the same: would you bet a containment action on this edge?

eBPF runtime sensors: direct observation

The base layer is kernel-level capture of the traffic the workload sends and receives. Most of it is TLS, so the sensor hooks the TLS boundary with uprobes on the SSL library (OpenSSL SSL_read/SSL_write), plus GoTLS for static Go binaries and a JVM path for Java. That is where the payload exists as plaintext, and where the sensor sees what never reaches an application log. (The SSL/TLS Trap covers why naive capture goes blind on encrypted traffic.)

For AI workloads it parses the protocols that matter, on top of a general protocol layer with connection tracking and PII classification (Protocol Intelligence Layer). It captures LLM traffic by host (openai.com, anthropic.com, Bedrock) and MCP, extracting the method (TOOL CALL, RESOURCE READ, and the rest) and labeling each side as AI_AGENT, MCP_CLIENT, or MCP_SERVER (From Packets to Agent Chains covers chaining these into workflows). When the agent calls GitHub or Slack over HTTPS, the same TLS-boundary capture path exposes the Authorization header in cleartext. The credential is fingerprinted, never stored raw. That a specific pod presented a specific fingerprint to github.com and issued a create-PR call is direct observation, the strongest edge in the graph.

Kubernetes API: authoritative binding

The sensor tells you which pod made the call. The Kubernetes API tells you what that pod is: its deployment, namespace, and service account, and from the service account the workload-identity binding (IRSA, Workload Identity, Pod Identity) to the IAM role and its permissions. This is an authoritative binding, not an inference: the cluster is the source of truth for which identity a pod runs as, which anchors the agent node to a real set of permissions and lets you compare granted against used.

CloudTrail: delayed corroboration

CloudTrail records the control-plane API calls the agent’s cloud identity makes. Different grade: delayed, and limited to cloud-provider calls, so MCP tool calls, LLM calls, and database queries never appear. Its value is the delta against eBPF. A call eBPF saw that CloudTrail confirms is corroborated; a CloudTrail entry with no workload-side counterpart is access that bypassed the application path (console actions, cross-account AssumeRole, automation outside the cluster). Use it for corroboration and gap detection, without relying on it as the primary record.

Identity integrations: resolved enrichment

This layer resolves delegated identity, and it is where the PAT problem gets solved on the evidence side. When the sensor observes a credential fingerprint, an integration resolves it against the issuing provider, where the provider’s API exposes that metadata. A GitHub PAT resolves to its owning user, email, MFA status, and the orgs and repos in scope; an OpenAI project key to its owning user or service account; a Slack token to its user and workspace via auth.test; an AWS or GCP identity to its IAM principal. What each provider exposes varies, so treat the fields as best-available. The lookup is keyed on the fingerprint; the raw credential is never stored.

The grade here is “resolved enrichment”: a lookup that attaches ownership and properties to an observed credential, rather than a direct observation of behavior. It is what turns “pod agent-7f8a used credential fp_9c2a” into “the agent acted as Alice’s PAT, which has org-wide repo scope and no expiry.” That single resolution exposes the delegation that GitHub’s audit log hides.

Putting this into practice at Aurva. The four sources above are the evidence layer we built: an eBPF sensor at the TLS boundary, Kubernetes informers for the service-account-to-IAM binding, CloudTrail for corroboration, and provider integrations that resolve a credential fingerprint to its owner. The grading matters more than the specific stack: whatever tool you use, ask what each edge is made of, and hold out for direct observation wherever a containment decision depends on it.

Stitching it up without losing the thread

Individually each source is a slice; the value is the join, which preserves context across every hop so the result reads as one chain. We cover the join mechanics, keys, and fragile spots in a companion post (Runtime Identity Attribution with eBPF, IAM, and CloudTrail). In short: the workload node comes from eBPF plus Kubernetes, the resource node from cloud metadata, the identity node from the credential resolution, all time-aligned so the LLM plan, MCP tool call, and GitHub write read as one sequence.

Applied to our incident, the stitched fact reads:

Every clause comes from a different source and grade. Remove the credential resolution and you are back to “Alice did it”; remove the eBPF layer and the MCP call and LLM plan vanish.

Why containment lives or dies on this

Here evidence grade stops being academic. With only GitHub’s audit log, your options are: notify Alice (wrong person), revoke her PAT (breaking her access and every other agent quietly sharing it), or do nothing. None stops the agent, which can just run again. With the stitched, graded evidence, containment becomes specific: you know the pod, its service account, the credential fingerprint, and the call, so you can block that pod’s egress to github.com, rotate the specific credential, and scope the replacement to the one repository the agent needs, all without paging Alice.

That is the link between the two halves of the premise: better evidence widens the set of containment actions you can safely take. Coarse evidence shrinks that set to “nothing” or “something destructive.” Precise evidence expands it to “the exact thing.”

The actual fix: stop delegating through a human’s PAT

The evidence tells you what is wrong; the remediation is a design change. A classic PAT is the wrong credential for an agent for three reasons the telemetry made visible: it is owned by a human, so every action attributes to that human; it is long-lived, so a leak is durable; and it is broadly scoped, so the blast radius is org-wide. Replace it with a credential that inverts all three:

• Agent-owned. A GitHub App installation token attributes actions to the app installation, not to whoever created a PAT, so the audit log finally names the agent.
• Short-lived. Installation tokens expire in about an hour; an OIDC-federated token minted per task lasts only that long. A leaked credential stops being useful quickly.
• Narrowly scoped. Grant the app the specific repositories and permissions the agent needs, not org-wide repo. That turns “could touch everything” into “can touch these three repos, read-only plus PRs.”

The telemetry then verifies the change worked: after the switch, the sensor should see the agent presenting a short-lived installation token that resolves to the app rather than a human, scoped to the repos you expect. A PAT fingerprint reappearing on that path is a regression worth an alert.

Honest limitations

• Resolution depends on the provider exposing owner metadata. GitHub, OpenAI, and Slack expose enough; some providers do not, or rate-limit the lookups. Where resolution fails, treat that edge as the lower grade it is.
• eBPF coverage stops at the host. Agents in serverless (Lambda, Fargate, Cloud Run) or fully managed SaaS are outside kernel visibility, so you fall back to control-plane logs, a real drop in grade.
• Fingerprint resolution has a freshness window. A credential’s owner, scope, or MFA status can change after it was last resolved; a stale resolution is weaker than a fresh one.
• The credential fix has ecosystem gaps. Not every tool supports app-style or OIDC-federated credentials yet. For the ones that still only offer long-lived tokens, scope tightly, rotate often, and lean on the telemetry to catch misuse.
• Containment is still a decision. Blocking egress or revoking a live credential has its own blast radius. Good evidence makes the action safe to consider; it does not remove the need for judgment.

Key takeaways

• Drawing an identity graph for AI agents is a bare minimum. Whether you can trust it, and act on it, depends on the evidence under each edge.
• Evidence comes in grades: direct observation from eBPF, authoritative bindings from Kubernetes, delayed corroboration from CloudTrail, resolved enrichment from identity integrations. They render the same on the graph and carry very different confidence.
• Shared PATs and API keys collapse every upstream identity into one credential owner, so the audit log names a human who did not act. Resolving the credential fingerprint to its owner exposes that delegation.
• Containment is the test. You can only revoke, scope, or block what you can attribute with confidence, and the fix for the PAT case is an agent-owned, short-lived, narrowly scoped credential that the telemetry can verify

Common Questions

Q: Why does an AI agent’s audit log name the wrong person?

Q: What is the difference between high-grade and low-grade attribution evidence?

Q: What should an AI agent use instead of a PAT to authenticate to tools?