Because agents frequently operate through borrowed service accounts or shared identities, downstream systems record the human account rather than the actual software actor. That collapses attribution and makes investigations harder. The fix is not a better human logon record, but actor-level telemetry that preserves who or what executed each action.
Why attribution breaks when agents act through shared identities
Agent logs usually inherit the identity context attached to the session, token, or service account that was used to execute the action. When multiple humans, automations, or workflows reuse the same credential path, the log records the borrower of the access path instead of the originating software actor. That is why investigation teams see a person-shaped trail where the real executor was an agent.
In practice, this is not just a naming problem. The audit trail is only as strong as the identity boundary behind it, and shared identities collapse that boundary. A useful mental model is to ask whether the log preserves actor identity, delegated authority, and request context separately, or whether it compresses them into one human account reference.
What actually has to be captured for reliable agent accountability
Reliable attribution needs more than a username. The minimum useful record is the actual actor, the delegated principal if one exists, the action, the target resource, and the policy decision that allowed it. In agentic systems, that usually means preserving correlation IDs, per-action authorization data, and the credential or token lineage that links the act back to the software entity that performed it.
When those fields are missing, downstream tools may still show a valid login event, but they cannot distinguish whether a human clicked, an agent planned and executed, or another workflow reused the same session. This is why “better login logs” often fail as a fix. The problem is not authentication alone, it is the loss of actor-level context after authentication has already succeeded.
For practitioners, the important distinction is between proving that an account was used and proving who or what used it. That distinction matters whenever agents use borrowed service accounts, shared workspaces, token exchange, or browser sessions that outlive the original user action.
How to redesign logs so investigations point to the right actor
The logging layer should be built around actor-centric telemetry, not just account-centric telemetry. Preserve a stable agent identifier, the human sponsor or owner where relevant, the delegated scope, and the exact tool or API call that was made. When agents operate on behalf of people, record the chain of delegation instead of collapsing everything into the last authenticating principal.
That is also where policy and audit must meet. If an agent can perform a material action, the log should show the authorization decision that allowed it, not merely the fact that a credential existed. NHIMG’s AI Agent Observability, Audit and Incident Response Guide is useful here because it focuses on what to log for agent actions, attribution, and incident response.
The same principle applies when you are choosing controls for delegation and access scope. If the system allows task-scoped access, per-action checks, or human approval gates, the logs should reflect those control decisions. NHIMG’s AI Agent Authorisation Guide helps connect those decisions to the audit trail rather than leaving them implicit.
For teams still sorting out the identity model itself, NHIMG’s Agentic AI Identity Guide is a strong companion because it frames registration, delegation, authentication, and retirement as separate identity events that should remain visible in logs.
Risk and Threat Considerations
Misattribution creates both operational and security risk. Investigators may blame the wrong user, miss the real execution path, or fail to see that a shared credential or delegated token was used across multiple workflows. In compromise scenarios, that ambiguity can hide abuse, delay containment, and make it harder to prove blast radius.
Failure mechanism: A shared account, reused token, or borrowed browser session collapses multiple actors into one logging identity, so the audit trail preserves access but not provenance.
Impact: Response teams lose confidence in the evidence, accountability becomes weak, and malicious or accidental agent activity can be misread as ordinary human use.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-10 — Human Use of NHI | Agent actions are misattributed when humans and non-human actors share identities. |
| NHI-04 — Insecure Authentication | Borrowed credentials and shared sessions obscure which actor actually authenticated. | |
| NHI-05 — Overprivileged NHI | Overbroad shared access increases the chance that multiple actors collapse into one audit trail. | |
| Recommendation — Separate human and non-human usage paths so logs retain the true actor behind each action. Bind authentication events to the actual agent identity and delegated context. Reduce shared privilege so each action is traceable to a narrow, accountable identity. | ||
| NIST SP 800-53 Rev 5 | AU-3 — Content of Audit Records | Audit records must include enough detail to identify the true actor and action context. |
| IA-5 — Authenticator Management | Credential reuse and borrowed tokens are a core cause of attribution collapse. | |
| IA-9 — Service Identification and Authentication | Agents and services often authenticate through non-human identities that need distinct traceability. | |
| Recommendation — Capture subject, object, event, and context fields that preserve action provenance. Manage credential lifecycle so reused authenticators do not blur actor provenance. Use distinct service and workload identities so logs can distinguish software actors from users. | ||
Practitioner Guidance
What to prioritise: Start with the actions that can change state, move data, or trigger downstream automation. Those are the events where actor-level attribution matters most and where a generic account log is least defensible.
What to verify: Check whether your logging pipeline preserves the originating actor, delegated principal, and request context end to end, especially after token exchange, session reuse, or service-account mediation. If that linkage disappears in any hop, attribution is already degraded.
Common mistake: Treating a successful human login as evidence of human execution. In agentic environments, the login is often only the start of the chain, not the proof of authorship.
Practitioner takeaway: Good attribution comes from preserving actor lineage, not from recording the last account that touched the system.