Mercari’s AI security model shows why agent identity needs guardrails

At a glance

What this is: Mercari’s security team describes how AI adoption is forcing security and governance models to treat agents as identities with explicit guardrails.

Why it matters: This matters because IAM, NHI, and human access programmes all break when runtime decisions, tool access, and accountability must be governed together.

👉 Read Opal Security's customer voice interview on Mercari's AI security guardrails

Context

AI security is becoming an identity governance problem because agentic systems can request tools, act on data, and make runtime decisions that were previously assumed to sit behind human-paced controls. Mercari’s view is that the important failure point is not AI itself, but the way existing authentication, authorization, and auditing layers were built for slower, more predictable access patterns.

For IAM and NHI teams, the practical shift is to treat agent behaviour as an access surface. That includes understanding which tools an agent can reach, which credentials it can use, and where governance needs to shift from periodic review to real-time containment and accountability.

Key questions

Q: How should security teams govern AI agents that can choose tools at runtime?

A: Security teams should govern runtime authority, not just credential issuance. That means defining which tools an agent may call, what data it may reach, and where human approval is required before chained actions continue. The control objective is to stop unauthorized scope expansion while preserving a clear audit trail for every decision the agent makes.

Q: Why do AI agents complicate traditional IAM and NHI controls?

A: AI agents complicate IAM and NHI controls because they act in ways that are not fully predictable at provisioning time. Traditional models assume entitlements can be reviewed after grant, but agent behaviour can change during a session, making static review and periodic certification too slow to contain the real risk.

Q: What do organisations get wrong about authorization for agentic AI?

A: They often treat authorization as a binary check at the front door, when agentic AI needs continuous evaluation across the whole action path. If the agent can invoke tools, pass data between steps, or trigger downstream actions, authorization must be visible at each point where authority changes shape.

Q: How do teams decide whether AI governance belongs in security, privacy, or platform engineering?

A: The decision should follow the identity behaviour being governed, not the organisational silo. Security owns access boundaries and auditability, privacy owns data use constraints, and platform teams often own the technical control points. The key is shared governance with clear ownership for each layer of the agent lifecycle.

Technical breakdown

Agentic AI identity and runtime authorization

Agentic systems change identity control because access is no longer just a login or token issuance event. The agent can select tools, decide when to act, and chain actions during a session, which means authorization must follow runtime behaviour rather than only provisioned entitlement. That creates failure modes such as confused-deputy behaviour, where an agent performs an action with authority it should not effectively wield, even if the underlying credential is valid. Central gateways help by constraining where requests pass, but the real issue is whether the authorization layer can reason about the agent's actual purpose in the moment.

Practical implication: map every agent to explicit tool scopes and decision boundaries before it is allowed to operate in production.

Authentication, API keys, and keyless access for AI systems

Mercari highlights the risk of over-prevalence of API keys when AI systems spread quickly across teams. API keys are easy to distribute, but they are also easy to copy, reuse, and leave in places where auditability is weak. Keyless authentication patterns reduce that exposure by binding access more tightly to workload or service identity, which is closer to how modern NHI governance should work. In AI environments, the question is not only whether the credential works, but whether the credential can be traced, constrained, and revoked without breaking the surrounding workflow.

Practical implication: reduce long-lived shared keys and prefer identity-bound, centrally managed access paths for AI workloads.

Auditing and accountability for LLM and MCP server usage

Mercari's focus on gateways and consultation reviews points to a broader control problem: AI toolchains often combine model calls, orchestration layers, and connected services in ways that are difficult to reconstruct after the fact. Auditing therefore needs to capture not just the request, but the agent's path through tools, the data touched, and the approval logic that allowed it. That is especially important for MCP servers, where the connection between model and tool can collapse traditional control boundaries if governance is not designed in from the start.

Practical implication: log agent-to-tool interactions with enough context to reconstruct intent, authority, and data access after the session ends.

Threat narrative

Attacker objective: The attacker aims to exploit delegated AI authority to expand access, misuse tools, or trigger harmful actions under valid identity context.

1. Entry occurs when an AI system is given broad access to model endpoints, tools, or connected services through shared credentials or loosely governed integrations.
2. Escalation happens when the agent uses those permissions to call more tools, reach more data, or carry out actions beyond the original human expectation.
3. Impact follows when misaligned or over-authorized agent behaviour creates unauthorized access, integrity loss, or difficult-to-trace operational damage.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agentic AI identity is no longer a niche control problem, it is an access governance problem. Mercari's description of AI Security, AI Governance, and centralized gateways reflects the reality that once agents can choose tools at runtime, identity controls become part of the execution path rather than a perimeter around it. Authentication, authorization, and auditing must be designed together because the failure mode is not simply unauthorized login, but authorized action taken with the wrong scope. Practitioners should stop treating agent identity as an extension of app security and start treating it as a first-class governance domain.

Least agency is the right framing for agentic AI, because least privilege alone is incomplete. Least privilege describes what a credential may access, but least agency describes what an agent is allowed to decide, sequence, and execute without human intervention. That distinction matters when business teams ask for autonomy and security teams inherit the resulting ambiguity about who is accountable when an agent acts correctly within the wrong objective. Practitioners should define both authority and decision boundaries, not just entitlements.

Identity does not select or combine tools dynamically mid-session was designed for human-paced or script-bound access. That assumption fails when the actor is autonomous because the agent can decide which tools to invoke, in what order, and at what moment without a human approval gate. The implication is that review-based governance cannot be the primary control plane for autonomous behaviour; the programme has to rethink whether access is still stable enough to observe after the fact.

Centralized AI gateways are a control pattern, not a governance outcome. They can narrow tool exposure and improve logging, but they do not by themselves resolve confused-deputy risk, misaligned delegation, or accountability gaps across product and enterprise AI use cases. Mercari's split between AI in products and AI in the enterprise is a useful signal that the governance boundary has to follow the actor and the use case, not the organisational chart. Practitioners should align control ownership with the actual identity behaviour being governed.

Agentic identity will compound existing IAM weaknesses rather than replace them. Mercari is right to note that many companies already struggle with IAM for employees, because the same lifecycle, audit, and authorisation discipline now has to extend to machine and agent identities. That makes inventory, owner assignment, and revocation harder, not easier, especially when AI systems are created quickly and distributed across multiple teams. Practitioners should expect agent governance to expose every weak point already present in the broader identity stack.

From our research:

• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging (37%) and over-privileged accounts (37%), according to The State of Non-Human Identity Security.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, including 38% with no or low visibility and 47% with only partial visibility.
• That visibility gap is why teams should pair access inventories with Ultimate Guide to NHIs , Key Challenges and Risks when mapping agent and workload access.

What this signals

Least agency: as agentic systems move from pilots to production, the control objective shifts from who can log in to what an actor is allowed to decide and execute. Teams that keep reviewing only entitlements will miss the runtime boundary where agent behaviour becomes risky, especially when models can chain tools and act faster than human review cycles can respond.

Mercari's split between AI Security and AI Governance is a sign that mature programmes will separate technical containment from policy ownership. For practitioners, that means aligning inventories, approvals, and audit trails with the actual actor type, while using the NIST Cybersecurity Framework 2.0 to keep governance, protection, detection, and response connected across AI-enabled workflows.

The next maturity step is not more AI-specific wording, it is better identity structure. The organisations that will scale safely are the ones that can answer, in one place, which agents exist, which tools they can touch, and which review process owns their offboarding when the use case changes.

For practitioners

• Define agent decision boundaries Document which actions an AI system may initiate, which tools it may chain, and where human approval is mandatory before execution continues. Treat those boundaries as part of the identity design, not as an afterthought added in a review meeting.
• Replace shared API keys with identity-bound access Move AI workloads away from long-lived shared secrets and toward centrally managed identity that is tied to workload or service context. This improves traceability, shortens exposure windows, and makes revocation possible without dismantling the full workflow.
• Instrument end-to-end audit trails for AI tool use Capture the model request, tool call, data accessed, and approval context so investigators can reconstruct what the agent did after the session ends. Logging only the final output is not enough to explain authorization failures or misuse.
• Separate AI product governance from enterprise AI governance Create distinct review paths for AI embedded in customer-facing products and AI used internally, because the risk, accountability, and data boundaries are not the same. One governance model will not fit both without creating blind spots.

Key takeaways

• Agentic AI turns identity into a runtime governance problem because tools, timing, and execution can all change during the session.
• API keys, weak auditing, and broad tool access are the recurring control failures that make AI systems hard to govern at scale.
• Practitioners need separate but connected controls for AI products, enterprise AI, and delegated agent behaviour to avoid blind spots.

Key terms

• Agentic AI identity: Agentic AI identity is the governance model for an AI system that can choose actions, select tools, and execute work with limited or no human approval. It extends identity controls beyond login and entitlement into runtime authority, auditability, and accountability for decisions made during execution.
• Least agency: Least agency is the principle that an AI system should be limited not only in what it can access, but also in what it can decide and trigger on its own. For autonomous actors, it is the practical complement to least privilege, because decision power can be as risky as data access.
• Confused deputy problem: The confused deputy problem occurs when a system with legitimate authority is tricked into using that authority for the wrong purpose. In AI environments, it appears when an agent or tool can take valid actions that do not match the intended user request, creating an authorization failure without an obvious login failure.
• MCP server: An MCP server is a tool-connected service that exposes capabilities and data sources to AI systems through a structured protocol. In governance terms, it becomes part of the identity perimeter because it can expand what an agent can reach, retrieve, or trigger during a session.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Opal Security: Customer Voices on how Mercari’s security team is building guardrails for the AI era. Read the original.