Organisations need telemetry that records which actions were initiated by a person and which were executed by an AI agent. Without that separation, audit trails become ambiguous, policy enforcement weakens, and accountability for sensitive actions is difficult to prove.
Why This Matters for Security Teams
Distinguishing human actions from automated AI tasks is not a logging nicety. It is the difference between a defensible audit trail and an ambiguous record that cannot support incident response, compliance, or accountability. For autonomous systems, the key issue is not only who authenticated, but whether the action was initiated by a person, delegated to an agent, or executed automatically inside a workflow. Current guidance increasingly points toward runtime identity and policy context, consistent with NIST Cybersecurity Framework 2.0 and agent governance work such as DeepSeek breach analysis, which shows how quickly AI-linked exposure can become an operational problem.
Security teams often get this wrong by assuming RBAC alone can separate people from machines. RBAC can say what a role may do, but it does not prove whether a request came from a human operator, an AI agent, or a chained tool call inside a multi-step automation. That gap matters when the same system can send email, approve payments, query production data, or call external APIs. In practice, many security teams encounter attribution failures only after a sensitive action has already been executed and the logs are too generic to reconstruct intent.
How It Works in Practice
The practical answer is to bind every action to a workload identity and preserve the human-to-agent relationship in telemetry. A human should authenticate once, then any delegated AI task should receive its own short-lived identity, ideally through JIT credential provisioning and ephemeral secrets. That lets the organisation record three separate events: the person who approved the task, the agent that executed it, and the resource that was touched. Where possible, teams should align this with workload identity patterns such as SPIFFE or OIDC-derived tokens, because cryptographic proof of the actor is stronger than reconstructing intent from application logs alone.
This is also where intent-based authorisation matters. Rather than granting a broad standing permission to an agent, policy should be evaluated at request time against context: what the agent is trying to do, which data it is requesting, which tool it wants to call, and whether the action matches the approved objective. That approach is more consistent with zero trust thinking and the NIST Cybersecurity Framework 2.0 than a static allow list. It also fits the reality highlighted in DeepSeek breach reporting: once AI systems can access secrets, prompts, files, or backend tools, attribution and containment must happen at execution time, not after the fact.
- Record the initiating user, the agent identity, and the executed tool call in separate fields.
- Issue short-lived credentials per task, not shared long-lived secrets for the whole agent fleet.
- Evaluate policy at runtime using context, not only pre-defined role membership.
- Tag downstream actions so security teams can trace whether a person, workflow, or agent triggered them.
Standards work is still maturing, but current guidance from OWASP-AGENTIC, CSA-MAESTRO, and the NIST Cybersecurity Framework 2.0 all point toward the same operational direction: identity must travel with the action. These controls tend to break down when agents can chain tools across multiple SaaS platforms because identity context is often lost between systems.
Common Variations and Edge Cases
Tighter attribution often increases engineering overhead, requiring organisations to balance better accountability against slower delivery and more complex integration. That tradeoff is especially visible in multi-agent workflows, where one agent may plan, another may retrieve data, and a third may execute a transaction. In those environments, a single “service account” is not enough, because it hides which autonomous step actually made the decision. Best practice is evolving, but there is no universal standard for this yet.
Some teams try to solve the problem with basic session logging, but that does not reliably distinguish a human click from an agentic API call. Others overcorrect by blocking automation entirely, which undermines the value of autonomous systems. A better pattern is to keep human approval explicit while giving agents constrained, revocable execution authority. That means separating human intent, agent execution, and system enforcement in both identity and logs.
Edge cases also appear when AI agents operate across legacy systems that lack modern identity hooks. In those environments, organisations may need compensating controls such as step-up approval, stronger PAM boundaries, and stricter JIT windows until workload identity is available. The important point is that the record must still answer the same question: did a person decide, or did an agent act within an authorised scope? Guidance from OWASP-AGENTIC and CSA-MAESTRO is increasingly aligned on that distinction, even though implementation details vary by platform and maturity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Agentic guidance applies to separating human intent from autonomous execution. | |
| CSA MAESTRO | MAESTRO covers agent governance, delegation, and traceable execution paths. | |
| NIST AI RMF | AI RMF supports accountability and governance for autonomous AI decisions. |
Instrument delegated workflows so human approval, agent action, and system enforcement stay distinct.
