AI agents expose a governance gap in platform policy and fraud rules

At a glance

What this is: This briefing argues that platform policies, access controls, and fraud rules built for human users are failing to distinguish beneficial AI agents from extractive automation.

Why it matters: It matters because identity, fraud, and security teams now need governance that can evaluate machine behaviour at runtime, not just authenticate a user once and assume the session remains human-driven.

👉 Read Netacea's executive briefing on the governance gap for AI agents

Context

AI agents change the governance problem because they can browse, transact, and extract data at machine speed while still acting on behalf of legitimate consumers. Traditional platform controls were written around human sessions, human intent, and human pacing, so they struggle when automation spans multiple sessions and behaves differently depending on the commercial goal.

The first-order issue is not whether automation exists, but whether organisations can distinguish useful agent activity from abusive extraction. That creates a direct identity governance intersection: if an agent is effectively acting as a non-human identity, then policy, authentication, and fraud controls have to work together instead of being managed as separate disciplines.

Key questions

Q: How should security teams handle delegated access when AI agents act on behalf of customers?

A: Security teams should treat delegated access as a separate governance layer, not as a normal login session. Define what the agent can do, how much value it can move, which approvals are required, and how delegation is revoked. Without those boundaries, the agent inherits more authority than the customer intended and fraud risk expands quickly.

Q: Why do human-first access controls fail for AI agents?

A: Human-first controls assume a person, a session, and an intent that stay relatively stable. AI agents can span multiple sessions, act at machine speed, and shift between browsing, transacting, and data extraction, which makes static allow and deny rules too blunt to separate legitimate automation from abusive use.

Q: What do organisations get wrong about bot detection and agent governance?

A: Many organisations treat bot detection as a perimeter problem when the real issue is governance across identity, access, and business rules. If a machine actor can still trigger revenue, access data, or complete transactions, detection alone will not tell you whether that activity is acceptable or harmful.

Q: Who should be accountable when an AI agent causes a security incident?

A: Accountability should sit with the human owner, platform team, or business function that granted and operated the agent. The identity may act independently, but governance cannot detach responsibility from the delegation chain. Programs should define ownership, escalation, and remediation paths before deployment so responsibility is clear when the agent's behaviour changes.

Technical breakdown

Why human-first policy models fail for AI agents

Most platform policies assume a stable relationship between identity, session, and intent. AI agents break that model because they can complete actions across multiple sessions, change timing dynamically, and use legitimate access paths in ways that still create commercial harm. The problem is not only authentication. It is authorisation at runtime, where the same automated actor may be acceptable in one context and abusive in another. That is why static allow or deny rules miss the operational reality of agentic traffic.

Practical implication: teams need runtime policy decisions that incorporate behaviour, purpose, and transaction context, not just login status.

Agent trust as a governance layer

An agent trust layer sits between coarse platform access and downstream decisions. In practical terms, it classifies machine actors, evaluates intent signals, and applies differentiated treatment to browsing, transaction, and data extraction flows. This is where identity governance becomes more than credential management. The control challenge is to decide whether a machine actor is authorised for the requested action, not merely whether it holds a valid token or passes a session check.

Practical implication: define explicit trust tiers for AI agents and map each tier to allowed actions, data access, and monitoring thresholds.

Emerging standards and the identity boundary for machine actors

The article points to emerging standards such as Visa TAP, Google AP2, and MCP because the ecosystem is moving toward more structured machine-to-service interaction. For identity teams, the key question is how these standards express trust, delegation, and tool use across sessions and services. MCP is especially relevant because it can connect AI agents to tools and data sources, which means governance must cover both the agent identity and the capabilities it can invoke.

Practical implication: assess new machine-access standards through an identity lens and require explicit controls for delegation, logging, and revocation.

Threat narrative

Attacker objective: The objective is to use legitimate-seeming automation to extract value faster than human-oriented controls can detect or classify it.

1. Entry occurs when AI agents browse or interact through legitimate platform pathways that were originally designed for people.
2. Escalation happens when the same agent reuses valid access across multiple sessions to harvest data, transact, or automate extraction at scale.
3. Impact is commercial and governance-related, including revenue leakage, fraud confusion, and loss of control over which automation is beneficial versus abusive.

NHI Mgmt Group analysis

Human-first policy is now a governance liability: platform rules built for consumer sessions cannot reliably classify agentic behaviour. The distinction between legitimate automation and extractive automation is now an identity governance problem as much as a fraud problem. Organisations should treat machine behaviour as a first-class policy input, not an edge case.

Agent trust is the right named concept for this gap: it describes the control layer that judges what a machine actor is allowed to do in a given context. That layer has to sit above authentication and below business decisions, because valid credentials alone do not tell you whether an agent is browsing, transacting, or extracting data for acceptable purposes. Practitioners should map trust tiers to transaction risk.

Existing controls fail when intent is not observable: access controls, bot rules, and fraud systems each see only part of the picture. The article correctly points to a governance gap, because platform policy cannot be reduced to blocklists when the same automation can drive revenue in one flow and erosion in another. Teams need policy that reflects purpose, pacing, and commercial context.

Machine identities now span commerce and security boundaries: the presence of MCP in the discussion is a reminder that agent tooling can connect directly to data and execution surfaces. That means NHI-style governance thinking matters even outside traditional IAM programmes, especially where delegated tools, shared sessions, and runtime decisions intersect. Security teams should bring identity governance into product and fraud design reviews.

Category maturity will be judged by decision quality, not traffic volume: the next phase of agent governance is not simply measuring how much non-human traffic exists. It is separating beneficial automation from abuse with enough confidence to preserve revenue while reducing fraud and data loss. Practitioners should build governance metrics around trust decisions, not just detection counts.

What this signals

The practical signal for security and fraud teams is that non-human traffic can no longer be treated as a single detection problem. The governance challenge is to distinguish acceptable agent behaviour from extractive automation in real time, and that requires shared policy language across IAM, fraud, product, and data governance.

Agent trust: this is the emerging control concept practitioners should watch. It describes the need to assign explicit trust and authority levels to AI agents so that delegation, transaction scope, and monitoring are governed as one control surface rather than split across disconnected tools.

For identity programmes, the forward risk is that machine actors will be routed through existing consumer controls until a serious loss forces redesign. Teams should prepare now by deciding which agent actions require step-up checks, which require revocation hooks, and which should never be allowed without human approval.

For practitioners

• Define agent trust tiers Classify AI agents by purpose, data scope, transaction authority, and revocation rules so platform policy can differentiate helpful automation from extractive behaviour.
• Map policy to runtime context Use session, pacing, and action context to decide when a machine actor can browse, transact, or access data instead of relying on static human-user rules.
• Unify fraud and identity governance Bring fraud, product, and security teams together around a shared control model so one team does not optimise revenue exposure while another only sees authentication events.
• Review machine-to-tool delegation Assess any emerging use of MCP or similar standards for where delegated tool access should be logged, limited, and revoked when trust changes.

Key takeaways

• AI agents expose a policy gap because human-first controls cannot reliably evaluate machine behaviour across sessions and transactions.
• The governance problem is not automation itself, but the inability to separate beneficial agent activity from extractive activity at runtime.
• Organisations need an explicit agent trust model that links identity, fraud, and product decisions to action-level authority.

Key terms

• Agent Trust Registry: A registry is a structured control record for AI agents that captures identity posture, trust signals, and governance metadata before production approval. In practice, it turns agent review into a repeatable decision process rather than a one-off judgment based on vendor claims or informal owner knowledge.
• Non-Human Traffic: Non-human traffic is any web or application activity generated by software rather than a person. In this context it includes bots, scrapers, and AI agents, all of which may be benign or harmful depending on intent, access scope, and business impact.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.

What's in the full report

Netacea's full research covers the operational detail this post intentionally leaves for the source:

• How Netacea frames the Agent Trust governance layer for live platform decisioning and traffic classification.
• The report's discussion of Visa TAP, Google AP2, and MCP as emerging standards shaping machine-to-platform interaction.
• The commercial distinction between beneficial automation and extractive automation in digital commerce and fraud contexts.
• The briefing's intended stakeholder view across digital, fraud, product, and security teams.

👉 The full Netacea briefing covers the standards discussion, Agent Trust framing, and commercial implications in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and identity lifecycle control. It helps practitioners connect identity policy to the broader security decisions their programmes now depend on.