Why do agentic systems complicate trust and authorization in online transactions?

Why This Matters for Security Teams

Agentic systems change online transaction trust because the requester, the software executing the action, and the merchant evaluating the request may all be different entities. That breaks human-centric fraud logic, where a cardholder, browser session, and purchase intent usually line up. With agents, a single transaction can be generated from delegated authority, chained tool use, or a partial prompt that was never meant to authorize payment.

That is why static account trust is no longer enough. Security teams need to know whether the system is proving identity, proving intent, or merely presenting a credential that was reused far outside its original purpose. Current guidance from the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework both point to runtime governance, not just account setup, as the control point.

NHIMG research shows the scale of the issue: in AI Agents: The New Attack Surface, 80% of organisations reported AI agents had already acted beyond intended scope, including unauthorised system access and credential exposure. In practice, many security teams discover these failures only after a disputed transaction, not through intentional testing of delegated authority boundaries.

How It Works in Practice

In an agentic transaction flow, the merchant should not assume that “logged in” means “authorised.” Instead, the system should evaluate whether the agent has a valid workload identity, whether the delegated authority matches the action, and whether the request is still within the allowed scope. This is where static role-based access control becomes too blunt. A role can say what an account may generally do, but it rarely captures what an autonomous agent may do right now, for this merchant, for this amount, using this task context.

Practitioners increasingly combine intent-based or context-aware authorisation with short-lived credentials. The agent presents proof of workload identity, often through OIDC-based assertions or identity fabrics such as SPIFFE/SPIRE, and then receives just-in-time access only for the task at hand. That access should be ephemeral, narrowly scoped, and revoked when the action completes. For online payments or order placement, the policy should inspect amount, destination, merchant category, time window, device or workload posture, and whether the action was explicitly requested by a human or by another approved system.

This model aligns with the shift described in OWASP NHI Top 10 and with the agent threat modeling approach in CSA MAESTRO agentic AI threat modeling framework. Real-time policy engines such as OPA or Cedar are useful because they evaluate the request at the moment of execution, not at onboarding. These controls tend to break down when merchants only see a delegated token and cannot validate the original intent chain or task-specific constraints.

Common Variations and Edge Cases

Tighter authorisation often increases friction, requiring organisations to balance fraud reduction against checkout latency, user experience, and support overhead. That tradeoff is especially visible in marketplaces, subscription renewals, and delegated purchasing, where a transaction may be legitimate even though the actor is not the direct customer.

There is no universal standard for this yet. Some environments may accept broad delegation with step-up verification for high-risk payments, while others need per-transaction approval and strict JIT issuance. The right model depends on whether the agent is acting on behalf of a consumer, a corporate buyer, or another machine. In higher-risk settings, merchant policy should explicitly distinguish between human presence, human approval, and autonomous execution, because those are not the same control condition.

Edge cases also appear when agents chain actions across systems. A task may begin as a harmless lookup, then trigger inventory changes, then reach payment authorization through a downstream tool. That is where zero-standing privilege and runtime policy evaluation matter most. Guidance from NIST Cybersecurity Framework 2.0 and emerging agentic guidance from OWASP Agentic AI Top 10 both support this direction, but implementation details still vary by payment rail and risk tolerance.

Related resources from NHI Mgmt Group

• What are MCP Authorization Extensions and how do they help organizations?
• What are the core risks identified by the OWASP Agentic Top 10?
• When does just-in-time access reduce risk for agentic AI, and when does it fall short?
• How should security teams govern machine identity credentials in agentic AI environments?