Achieving Agent Visibility Across the Enterprise

Overview

Take a support agent that, for eight months, only ever read account records. This month it started editing them. Nobody approved that change, and nobody would have caught it either, unless whoever went looking already knew which systems to check and in which order.

That's the actual shape of the problem. An enterprise running a dozen agents almost certainly has enough logs already. The real question, with an unhappy customer on the phone, is whether anyone can answer "who did this, on whose behalf, and under what permission" without opening six tabs and reconciling timestamps by hand. A procurement agent that authenticates through the identity provider, calls a supplier API, writes to the ERP, and posts a summary to a messaging channel leaves four separate footprints. No single system sees the sequence.

This post is about the sequence an actual investigation runs: what to check first, second, and third, and what each step needs to be able to answer before you move to the next.

Why It's Scattered by Default

Agents reach enterprise systems through several different doors, and each door keeps its own record. An API call with a long-lived key lands in one log. An OAuth grant that inherits a user's scopes lands in another. A service account with no human in the loop, a browser session driving a UI like a person would, a delegated grant that borrows someone else's standing access — each of these is real signal, and each lives in a system that has no reason to know the others exist.

The problem isn't that any one of these logs is bad. A cloud audit trail is usually excellent at recording what happened in the cloud. It just has no way to say that the actor was an agent, or which team that agent was working for, because from its point of view an API key is an API key. The fragments are individually honest and collectively silent about the one thing you need: the agent, followed across all of them.

What You Pull Up First

An investigation that starts with "let's check the logs" is already behind. The useful version starts with a fixed sequence, run against one identifier, every time.

Figure 1 — The sequence an investigation actually runs, correlated by a single agent identifier rather than reconstructed after the fact.

Each step below is one question, not a category of telemetry to collect for its own sake. Skip a step and the next one has no context; run them out of order and you'll chase the wrong lead.

Who Acted, and On Whose Behalf

Skip straight to "what happened" and you're already chasing the wrong thread. Ask "which agent, and acting for whom" first — everything else you check gets filtered by that answer.

This matters more for agents than for people, because the failure mode is different. If the support agent above acts under its own service identity, every edit is attributable to it directly. If it instead borrows a human agent's session, the edits disappear into that person's ordinary traffic, and the question "did the agent do this or did the person" becomes unanswerable after the fact rather than merely inconvenient. Confirming identity first is what makes every later step point at the right actor instead of a plausible one.

What It Was Allowed to Do

Once you know who acted, check what that identity was permitted to do, and compare it against what actually happened. The gap between the two is the signal.

A legal-review agent that holds read access across a contract repository but has only ever touched a handful of templates has a narrow, boring gap — expected and stable. The support agent that starts editing records is a gap that widened suddenly. Whether the cause is a misconfiguration, a manipulated prompt, or scope nobody remembered to remove, the authorization check is what turns "it did something odd" into "it did something it wasn't supposed to be able to do," which is a different and more urgent finding.

What It Actually Did

With identity and authorization established, pull the actual calls. Most of what an agent does, it does through tools, and a useful record answers four things for each call: which tool, what action, what data, what result.

{
  "agent_id": "agent.support.account-editor",
  "acting_for": "team:support-tier2",
  "tool": "crm.accounts",
  "action": "update",
  "params": { "account_id": "A-88231", "field": "billing_address" },
  "permission": "accounts:read",
  "result": "denied",
  "ts": "2026-06-22T14:08:11Z"
}

That single line, permission accounts:read against an attempted update, is worth more than a week of dashboard scrolling. It tells you the boundary held, which shifts the investigation from "what got changed" to "why did the agent try in the first place." Without call-level detail, you'd only know the CRM saw a write attempt from somewhere.

Which Credential Carried It

Agents reach systems using tokens, keys, and grants, and the credential itself is worth tracing separately from the call it made. The signal here is drift between a credential and the job it was issued for.

A key that keeps getting exercised long after the agent it belonged to was supposed to be retired, or a credential suddenly used against a system it has never touched before, is exactly the kind of thing that stays invisible when credential events sit in a secrets manager nobody cross-references against agent activity. Tracing the credential is what tells you whether the problem is the agent's behavior or something narrower: one key that should have been rotated out.

Whether the Trail Holds Together

The last question is whether everything above resolves into one record, months later, for someone who wasn't in the room. A durable audit trail is what lets a security team answer a regulator's question, an engineer trace a bad outcome to a specific decision, and anyone confirm that a permission check actually ran before an action went through.

This only works if every fragment carries the same agent identifier. An agent that shows up as one ID in the cloud console, another in the SaaS audit log, and an OAuth client ID somewhere else will always read as three unrelated actors, no matter how good each individual log is. Carry one identifier through every system, and the cloud role assignment, the token issuance, and the CRM's denied write all resolve to a single thread instead of three fragments that happen to share a timestamp.

In Practice

Back to the support agent. On its own, the CRM shows a denied write. The identity provider shows a token issued an hour earlier. Nothing else, by itself, looks like an incident.

Followed as one thread, tagged by agent identity, the sequence reads differently: the agent authenticated as itself, acting for the tier-two support team, held accounts:read, and attempted an update that the authorization layer refused. The credential it used was current and correctly scoped. Nothing was actually changed. Somebody's prompt asked the agent to do something its permissions wouldn't allow, and the permissions won. That's a product or training question, not a security incident.

That's the payoff of running the sequence instead of searching from scratch: five minutes to a specific, correct answer instead of an afternoon spent confirming that nothing happened.

Conclusion

Agents will keep spreading across clouds, SaaS platforms, and internal tools, and no amount of consolidation will make them log through one system. Visibility doesn't depend on that happening. It depends on a stable agent identity carried into every system an agent touches, and a fixed order of questions run against that identity: who acted and for whom, what they were allowed to do, what they actually did, which credential carried it, and whether the record holds together months later.

None of that requires new telemetry. What we think it requires is deciding, before anything goes wrong, what you'll open first.