Can Your Security Platform Show Who the Agent Was Acting On Behalf Of?

One question cuts through a lot of agent security theater.

Who was the agent acting on behalf of?

That sounds simple, but it is the point where visibility turns into accountability. If a platform can show that an agent opened a pull request, changed a ticket, queried a database, or triggered a cloud action, that is useful. If it cannot show whose authority the agent was using when it did that work, the evidence trail is still incomplete.

That is why GitHub's current enterprise Copilot docs matter. GitHub now gives enterprise owners a practical way to monitor agentic activity, review recent sessions in AI Controls, drill into activity from the last 24 hours, and inspect agentic audit events over the last 180 days. More importantly, the agentic audit event model makes the identity chain more legible by surfacing fields like action, actor_is_agent, agent_session_id, and user.

That gives buyers a strong standard for evaluating agent accountability. The question is no longer whether a vendor can show "agent activity." The question is whether the platform can preserve responsibility from the human initiator to the agent session to the resulting action.

Why "acting for" is the real test

The security problem is not only "what did the agent do?"

The harder questions are:

• who initiated the task
• which session carried the work forward
• which identity or authority the agent used at each step
• what changed in the target system
• whether investigators can reconstruct that chain later

A platform that cannot answer those questions usually falls back on vague assurances about monitoring, AI governance, or policy. That is not enough for incident review, access control validation, or buyer confidence during procurement.

When teams adopt agents across code, ticketing, cloud, and internal tools, the accountability model gets harder fast. An agent may start in one interface, call a connector, cross into a third-party app, then invoke a custom tool or MCP server. Every hop is a chance to lose the link between the initiating user and the action that actually happened.

What GitHub surfaces today

GitHub now gives enterprise owners a more operational way to inspect agent activity.

According to the current docs, teams can:

• review the three most recent agent sessions in AI Controls
• open the full list of sessions from the last 24 hours
• filter sessions by agent, organization, repository, status, timeframe, and user
• jump from AI Controls into audit logs covering the last 180 days
• use the actor:Copilot filter in the enterprise audit log to isolate agentic events

That matters because it gives security teams two different kinds of evidence:

• a live or near-live operating view of what agents are doing now
• a longer historical record for investigation and compliance review

GitHub is also clear about an important boundary. Its audit-log docs say the audit log does not include client session data such as prompts a user sends to Copilot locally. GitHub also recommends streaming the audit log to a SIEM for longer-term history and alerting. That kind of disclosure is useful for buyers because it shows where the official evidence trail ends and where a separate logging strategy may be required.

The four fields that matter most

GitHub's audit event reference is especially helpful because it names the fields that turn activity into accountability.

• action shows what the agent did
• actor_is_agent confirms the actor was an AI agent
• agent_session_id ties the event back to the specific session
• user shows who initiated the event

That is already a better model than many platform demos, because it connects action, agent status, session lineage, and initiating human identity in one event structure.

But buyers should push one step further. Those four fields are the start of an accountability model, not the end of one.

What strong delegated identity looks like

If you want to know who an agent was acting for, a serious platform should be able to preserve at least six things together:

• the initiating human identity
• the agent or workflow identity
• the session identifier
• the permission context or delegated authority used for the step
• the target system or resource touched
• the resulting state change or output

In other words, investigators should be able to say something like this:

"Alice initiated session abc123. The agent used scoped write access in repository payments-service, created pull request #482, and later called a ticketing workflow tied to the same session."

That level of reconstruction is what separates a real audit trail from a decorative activity feed.

What buyers should ask in demos

Keep the demo questions concrete and operational.

1. Show one action tied to one user and one session

Do not accept a dashboard summary alone. Ask the vendor to show a single action and trace it back to the initiating user and the session that produced it.

2. Show the exact filters an investigator would use

GitHub's agent-session filters are useful here because they mirror how real reviews work. Ask whether you can isolate activity by user, repository, organization, status, timeframe, or agent type without exporting raw logs first.

3. Show how agent actions are separated from human actions

Clear separation matters during incident review. If the product cannot distinguish between human and agent activity cleanly, the audit trail becomes harder to trust.

4. Show what authority the agent used at the moment of action

This is where many demos get vague. It is not enough to know who started the task. Buyers should also ask which scoped credential, role, token, or delegated permission the agent used when it made the change.

5. Show what happens after the first system hop

Ask the vendor to follow the same session into the next tool, connector, or MCP server. If identity continuity disappears as soon as the agent leaves the first platform, the accountability story breaks exactly where most real workflows begin.

6. Show what falls outside the log

GitHub explicitly documents that local prompt data is outside the audit log. Strong platforms should be equally direct about blind spots, retention limits, and any places where a separate SIEM or telemetry pipeline is required.

Where most platforms break

Most organizations do not run agent workflows inside one neat boundary. The evidence trail usually gets thinner when the session crosses from code into cloud, ticketing, identity, messaging, or internal tools.

Common failure modes show up quickly:

• the platform records that "an agent acted" but drops the initiating user
• the session identifier changes or disappears across tools
• a shared service account hides who the agent was actually acting for
• approval decisions are logged separately from the action they authorized
• downstream systems show the result, but not the causal chain that led there

That is why delegated identity has to survive more than the first log entry. Security teams need to know whose authority the agent used, which systems it touched next, and what evidence still exists when the investigation expands beyond the original control plane.

The practical buying standard

A good platform should let a buyer answer five questions quickly:

• Who initiated the work?
• Which agent session performed it?
• What authority did the agent use?
• What systems changed?
• Can that evidence be recovered later without guesswork?

If the vendor cannot answer those questions live in a demo, the platform probably does not yet have an end-to-end accountability model.

FAQ

Why is "acting for" a stronger question than "what did the agent do"?

Because actions without attribution do not tell you whose authority was being exercised. Security teams need both the activity and the responsibility chain.

Is a user field enough by itself?

No. A user field is useful, but buyers also need session lineage, agent identity, permission context, and downstream evidence if they want to reconstruct what actually happened.

Are 180 days of audit history enough?

Not always. GitHub's current docs say enterprise audit logs retain the last 180 days, and GitHub recommends streaming logs to a SIEM for longer-term history and alerting. Buyers should ask every vendor what long-term retention and export path looks like.

Does the audit log capture every prompt or local action?

No. GitHub's current docs say the audit log does not include local client session data such as prompts sent to Copilot locally. That is a useful reminder that even strong audit models still have boundaries.

What should a vendor be able to prove in a live demo?

At minimum: one initiating user, one agent session, one concrete action, one permission context, and one clear output or state change that can be traced across the workflow.

If you want to see how Cantina keeps agent identity, session context, and downstream evidence connected across the whole workflow, book a platform walkthrough.