Organisations should define clear accountability before deployment, not after an agent causes a transaction. The operating model needs named human owners, approval boundaries, audit logging, and escalation paths for disputed or harmful actions. If an AI agent can browse, decide, and transact, governance must specify who authorises the agent, who monitors it, and who responds when the agent exceeds intent.
Why This Matters for Security Teams
Accountability becomes difficult the moment an AI agent can take an action that looks like a user action but is actually executed by software with its own tool access. That distinction matters because the agent may chain prompts, call APIs, move data, or initiate payments outside the narrow intent a user had in mind. Current guidance suggests treating this as an identity and control problem, not just a UX problem. NIST’s NIST AI Risk Management Framework and OWASP’s OWASP Agentic AI Top 10 both point to governance, traceability, and misuse resistance as core requirements, not optional add-ons.
For security teams, the real issue is who owns the decision when an agent oversteps, whether that is a fraudulent transaction, a mistaken transfer, or an action that violates policy but was technically permitted. NHIMG research on OWASP NHI Top 10 shows that agentic systems inherit the same secret and identity fragility as other NHIs, but with far higher blast radius when those identities can transact. In practice, many security teams encounter accountability gaps only after an agent has already executed an unwanted transaction, rather than through intentional approval design.
How It Works in Practice
Organisations should assign accountability across three layers: authorisation, oversight, and incident response. The person or team that approves deployment is not necessarily the person who approves each transaction. For high-risk actions, the best practice is evolving toward intent-based approval: the agent can propose an action, but runtime policy decides whether the action is allowed based on context, risk, amount, destination, and session state. That aligns with the broader direction of CSA MAESTRO agentic AI threat modeling framework and NIST AI Risk Management Framework.
In practice, this means the operating model should define:
- a named business owner for the agent’s purpose and limits
- a technical owner for policy, logging, and credential governance
- a control owner for disputed actions and rollback
- clear thresholds for when the agent can act autonomously versus when it must escalate
- immutable audit logs that record the user intent, model output, policy decision, and final transaction result
Where agents can initiate transactions, workload identity becomes critical. The agent should present cryptographic proof of what it is, not just reuse a long-lived secret. That is why runtime-issued credentials, short TTLs, and step-up controls matter more than traditional static roles. NHIMG’s LLMjacking analysis shows how quickly compromised AI credentials can be abused, which is exactly why transaction authority should be narrow, temporary, and revocable. These controls tend to break down when agents are embedded in legacy workflows that assume one human equals one durable session because the transaction trail no longer reflects who actually exercised control.
Common Variations and Edge Cases
Tighter transaction controls often increase friction, requiring organisations to balance user convenience against fraud prevention and compliance evidence. That tradeoff becomes visible in edge cases such as delegated purchasing, customer support agents, treasury workflows, and cross-system automation where a human may initiate a task but the agent completes it much later. Guidance suggests the accountability chain should follow the decision surface, not just the login session, but there is no universal standard for this yet.
One common mistake is assigning blame to the model vendor when the real failure was internal: unclear approval boundaries, weak secrets hygiene, or absent review thresholds. Another is assuming a single human can own both product outcomes and transaction disputes at scale. For sensitive workflows, separate the roles of sponsor, operator, and reviewer, and require policy-as-code decisions at request time. This is especially important when agents use external tools or payment rails, because a permitted action can still be harmful if the context has changed since the user’s original request.
NHIMG’s reporting on OWASP Agentic Applications Top 10 reinforces that prompt injection, tool abuse, and secret exposure are not theoretical concerns. Organisations should therefore define who is accountable for each layer of control, not just who clicked start. If the environment mixes autonomous agents, shared service accounts, and legacy PAM processes, accountability models often collapse because the evidence trail is fragmented across too many identity systems.
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, OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A5 | Agent autonomy creates misuse and transaction-abuse risk. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Agent transaction authority depends on secret lifecycle and revocation. |
| CSA MAESTRO | GOV-1 | Accountability needs named owners, approval gates, and escalation paths. |
| NIST AI RMF | GOVERN | AI governance requires traceability, roles, and human oversight for actions. |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Zero trust supports contextual authorization for each transaction. |
Document responsibility, decision rights, and auditability for each agentic transaction path.
