One of the most technically specific points in the open letter on collective cyber defense is this one:
“Build observability and security tools, ensure agentic identities are traceable and accountable, and share best practices in continuous monitoring.”
It’s a relatively new problem for most security teams: this isn’t about auditing what a human user or a traditional service account did, but what an AI agent did while acting autonomously or semi-autonomously, potentially chaining together multiple tool calls, systems, and APIs. This guide is about building that traceability from the ground up.
Why agentic identities break traditional audit models
A classic audit log answers “which user performed this action?” With AI agents, the right question is multi-layered: which agent, invoked by which user or process, given what prompt or instruction, executing which tool, with what inherited permissions, as part of what decision chain? If your logging system doesn’t capture those layers, you have a non-traceable identity — exactly what the letter is asking you to fix.
Step 1 — Design the agent’s identity model
Before instrumenting anything, define how an agent is identified in your system:
- A unique, persistent identity per agent (don’t reuse the same service account credential for multiple agents with different purposes).
- Explicit link from agent → responsible human owner/team. Every agent has an owner, no exceptions — just like a service account should have one today.
- Permission scope tied to the task, not the whole system. An alert-triage agent doesn’t need write access to production.
Step 2 — Instrument the full decision chain
For every action an agent executes, record at minimum:
| Field | Why it matters |
|---|---|
| Unique session/invocation ID | Lets you reconstruct the full chain of a task |
| User or process that invoked the agent | Origin accountability |
| Prompt/instruction received | Context for why it acted that way |
| Tools invoked and parameters | Concrete actions it took |
| Result of each tool call | What information the agent had to decide its next step |
| Effective permissions at the time of the action | Audit whether it acted within its authorized scope |
| Timestamp of each step | Temporal correlation with other security events |
json
{
"session_id": "agent-run-8f2a1c",
"invoked_by": "user:jsmith / service:incident-triage-pipeline",
"agent_identity": "agent:soc-triage-01",
"owner_team": "security-ops",
"steps": [
{
"tool": "query_siem",
"params": {"query": "alert_id:4471"},
"timestamp": "2026-08-30T14:02:11Z",
"permissions_used": "read:siem"
},
{
"tool": "isolate_host",
"params": {"host": "srv-042"},
"timestamp": "2026-08-30T14:02:19Z",
"permissions_used": "write:network-isolation",
"approval_required": true,
"approved_by": "human:analyst_gperez"
}
]
}Step 3 — Real accountability: human approval for irreversible actions
Traceability without accountability controls is just a nice-looking log after the fact. For high-impact or irreversible actions (isolating a production host, revoking credentials, modifying firewall rules), the design must enforce:
- An explicit approval gate before execution, not just after-the-fact logging.
- Technical impossibility for the agent to self-approve (separation between requester and approver, the same way financial controls work).
- Timeout and safe fallback: if approval doesn’t arrive within a reasonable time, the agent must fail safe (not execute by default), except in explicitly pre-authorized low-criticality scenarios.
Step 4 — Continuous monitoring of agentic behavior
Beyond the audit log, instrument anomaly detection specific to agents:
- Deviation from normal tool-usage patterns: a triage agent suddenly invoking tools outside its usual set is a red flag (possible prompt injection or misuse).
- Anomalous action volume: an agent executing 500 actions in a minute when its baseline is 5 per minute.
- Attempts to escalate permissions or access resources outside scope, which should be blocked at the policy level but should also trigger alerts if attempted.
Step 5 — Share the model, not just use it internally
The letter explicitly calls for “sharing best practices in continuous monitoring.” If your organization participates in an ISAC or sector-specific threat-intelligence sharing group, consider sharing (anonymized) patterns of anomalous agentic behavior you’ve detected — this connects directly to the collective-defense approach covered in the threat intelligence sharing post.
Implementation checklist
- ☐ Assign a unique, persistent identity to each agent, with an explicit human owner
- ☐ Instrument logging of the full chain (invocation → tools → results → effective permissions)
- ☐ Implement a mandatory human approval gate for irreversible actions
- ☐ Configure safe fallback on approval timeout
- ☐ Deploy anomaly detection for agentic behavior (pattern, volume, escalation attempts)
- ☐ Evaluate which anonymized patterns could be shared with your ISAC or sector group
Part of a series on how to put into practice the principles from OpenAI’s open letter on collective cyber defense (August 2026). Back to the full guide.
