By NHI Mgmt Group Editorial TeamBased on Opal Security: “Customer Voices: How Mercari’s Security Team is Building Guardrails for the AI Era” (November 3, 2025)

TL;DR: Opal Security says Mercari moved AI security from functional silos into a dedicated governance model as LLM and agentic AI adoption accelerated, with focus on authentication, authorization, auditing, tool control, and least agency. The governing assumption has changed: agentic behaviour turns identity into runtime governance, not a static entitlement record.


At a glance

What this is: This is Opal Security’s customer voice analysis of how Mercari is formalising AI security, with agent identity, tool control, and governance guardrails treated as a dedicated security domain.

Why it matters: It matters because IAM teams now have to govern AI agents as identities with runtime behaviour, not as ordinary users or fixed service accounts.

👉 Read Opal Security’s analysis of Mercari’s AI security model and agent guardrails


Context

Mercari’s security team describes a shift from treating AI as a topic owned by individual functions to managing it through a dedicated AI Security capability. In practical terms, that means security, privacy, and governance are being pulled closer to the point where AI systems are built, connected, and allowed to act.

The core governance problem is not simply that AI is spreading. It is that agentic AI changes the control surface from static access assignment to runtime decision-making, where authentication, authorization, auditing, and tool boundaries all have to hold while the system is acting.

That is why this story sits at the intersection of NHI governance and emerging agentic AI identity practice. The underlying question is how to keep least privilege meaningful when the actor can initiate actions, call tools, and move through workflows with increasing independence.


Key questions

Q: What breaks when agentic AI is governed like a normal application account?

A: Security controls break down because agentic systems do not behave like fixed-function applications. They can choose actions at runtime, combine tools in unexpected ways, and move faster than periodic review cycles. That means static roles, annual recertification, and one-time approvals do not fully describe the risk or contain the behaviour.

Q: Why do AI agents create more risk than traditional automation?

A: AI agents create more risk because they can interpret context, choose actions, and invoke tools autonomously. Traditional automation follows fixed rules, but an agent can be manipulated into using its own authority in unintended ways. That makes permission scope, tool boundaries, and monitoring more important than model accuracy alone.

Q: What are the signs that agent tool access is becoming overprivileged?

A: Warning signs include broad tool lists, direct connections to internal systems without a broker, and authorization checks that happen only at login or launch. If the agent can continue to accumulate effective privilege as it moves through tasks, the control boundary is too loose and the governance model is already behind the runtime behaviour.

Q: How should security teams govern AI agents that can access enterprise systems?

A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.


Technical breakdown

Why agentic AI pushes identity from entitlement to runtime governance

Agentic AI changes the identity problem because the system does not just consume access, it can choose actions during execution. That matters for identity governance because a static entitlement view assumes access can be reviewed after the fact, while an agent can acquire, use, and chain capabilities inside one task. Mercari’s discussion of least agency, circuit breakers, and rogue agents reflects this shift from permission records to behavioural control. Authentication, authorization, and auditing still matter, but they must be enforced at the moment the agent acts, not only when access is issued or reviewed. Practical implication: design controls around decision points, not just around provisioned roles.

Practical implication: move control enforcement to runtime decision points, not just provisioning and review cycles.

How tool control and MCP gateways reduce agent supply-chain exposure

When AI systems connect to tools through MCP servers or similar integrations, the risk is not only data exposure but uncontrolled capability sprawl. Each connected tool expands the agent’s effective authority and creates a supply-chain-like trust problem: if the tool surface is too broad, the agent can reach functions it should not use. Mercari’s emphasis on centralized gateways is a way to keep tool selection and access within a governed boundary. This is an NHI-adjacent control issue because the agent’s effective privilege is defined by the tools it can invoke, not just by the account that launched it. Practical implication: inventory, broker, and constrain every agent-facing tool connection.

Practical implication: inventory, broker, and constrain every agent-facing tool connection.

Why the confused deputy problem matters in AI security governance

The confused deputy problem appears when an agent or intermediary uses its own authority to act on behalf of a requester in ways that were not intended. In AI security, that can happen when authorization is validated loosely or when the system cannot distinguish the agent’s intent from the user’s request. Mercari’s concern here is less about a single bug than about a governance boundary that becomes blurry once AI can initiate or chain actions. This is where auditing alone is insufficient: the issue is not just proving what happened, but preventing the system from acting beyond the delegated purpose. Practical implication: test agent authorization paths for scope confusion before broad deployment.

Practical implication: test agent authorization paths for scope confusion before broad deployment.


NHI Mgmt Group analysis

Agent identity is becoming a governance category, not a side effect of automation: Mercari’s framing shows that once agents can make runtime decisions, identity governance has to account for behaviour, not just assignment. The important shift is that the control subject is no longer a user or workload alone, but an actor that can select actions and tools during execution. That makes least privilege harder to define in advance and harder to validate after the fact. Practitioners should treat agent identity as a first-class governance model, not an extension of existing IAM.

Least agency is the right counterweight to agentic expansion: Mercari’s emphasis on circuit breakers and misalignment points to a broader principle. When the business wants more autonomy from AI, the governance response cannot be unlimited trust plus retrospective review. The practical boundary is least agency, meaning the agent should be able to do only the minimum required for the task and should be interruptible when behaviour drifts. That is a control philosophy, not a product feature, and it belongs in policy as much as architecture.

Tool control is where AI security becomes NHI governance by another name: As soon as the agent can reach external tools, the real privilege boundary becomes the tool chain. That is structurally similar to NHI governance because access scope is determined by credentials, tokens, connectors, and delegation paths, even when the actor is more dynamic than a service account. The named concept here is the runtime governance gap: the distance between static approval and dynamic execution. Practitioners need to close that gap before agent use spreads across business workflows.

Authentication, authorization, and auditing must move closer together: Mercari’s approach shows that treating these controls as separate back-end functions is no longer enough. If identity is evaluated in one system, authorization in another, and audit after the session, then agentic behaviour can outrun the governance loop. That does not mean abandoning established IAM practice. It means re-anchoring those controls so they are evaluated in the same operational moment. For security teams, the implication is that AI governance and IAM governance are now overlapping disciplines.

AI governance will increasingly look like lifecycle governance for a new class of actor: Mercari’s move toward dedicated governance and automated inventories signals where the field is heading. The issue is not only whether an agent exists, but whether it is known, classified, bounded, and removable when no longer needed. That is lifecycle thinking applied to an actor that can operate without direct human supervision. The implication is clear: identity programmes will have to manage agent onboarding, change, review, and retirement with the same seriousness they already apply to privileged human and machine access.

What this signals

Runtime governance gap: The control problem is no longer whether access exists, but whether an agent can still be constrained once it begins to act. That means identity, tool brokerage, and audit logic have to converge at execution time, or review processes will always trail the behaviour they are meant to govern.

Mercari’s approach suggests that AI security programmes will mature from ad hoc reviews into actor-based governance, where agents are inventoried, bounded, and retired like other sensitive identities. That shift will matter most in environments where AI tools connect directly to internal systems and regulated workflows.


For practitioners

  • Define agent identity as a governed access class Treat agentic systems as actors whose privileges, tool access, and delegation scope must be explicitly classified and reviewed, rather than folded into generic application access.
  • Broker every tool connection through a control point Centralise access to MCP servers, internal APIs, and other AI-connected tools so that the agent never receives direct, unconstrained reach to downstream systems.
  • Test for confused-deputy behaviour before rollout Validate whether the agent can be induced to act with authority that exceeds the original request, especially where user intent and system authority can be mixed.
  • Add circuit-breaker conditions to agent workflows Build intervention points that can pause, limit, or isolate an agent when its actions drift from the authorised business purpose or produce unexpected tool use.
  • Maintain an inventory of AI usage and delegated access Track which agents exist, what functions they touch, which tools they can invoke, and when those permissions change or expire.

Key takeaways

  • Agentic AI changes the identity problem because the actor can make runtime decisions, so governance has to move beyond static entitlement records.
  • Tool access, authorization boundaries, and audit loops become more fragile when AI systems can choose how to act during execution.
  • Security teams should classify agents explicitly, broker tool access, and build interruption points before agent use spreads into core workflows.

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 OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10ASI03 — Identity & Privilege AbuseThe article centres on agent identity, authorization, and least agency for AI actors.
ASI02 — Tool MisuseMercari highlights tool control and MCP gateways as core AI security concerns.
ASI09 — Human-Agent Trust ExploitationConfused-deputy risk and delegation boundaries are central to this discussion.
Recommendation — Constrain agent authority and review privilege boundaries where runtime decisions can expand access. Broker tool access so agents cannot invoke downstream systems outside approved scope. Validate delegation paths to ensure user intent cannot be converted into broader agent authority.
OWASP Non-Human Identity Top 10NHI-04 — Insecure AuthenticationThe article explicitly discusses keyless authentication and agent identity as a control issue.
NHI-05 — Overprivileged NHIMercari’s least-agency framing is fundamentally about avoiding excess effective privilege.
Recommendation — Use strong authentication patterns for agent access and reduce dependence on exposed API keys. Limit agent permissions to the minimum tool and data scope required for each task.
NIST AI RMFGOVERN — AI Governance and AccountabilityThe article is about standing up governance structures for AI security and oversight.
Recommendation — Establish clear ownership, policy boundaries, and accountability for agentic AI use.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsAuthorization and access control are explicit focal points of the article.
Recommendation — Align agent permissions to the minimum authorised scope and revalidate them as use cases change.

Key terms

  • Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
  • Least Agency: The agentic equivalent of least privilege, the principle that AI agents should be granted only the minimum level of autonomy necessary to complete their designated task, and no more. Coined in the OWASP Top 10 for Agentic Applications 2026.
  • Confused Deputy: A confused deputy is a privileged system that is tricked into performing an action on behalf of an untrusted requester. In agentic AI, the agent may misread malicious input as legitimate intent and then use its own authority to act, which turns a logic problem into a security incident.
  • Governance Gap: A governance gap is the distance between knowing an asset exists and being able to enforce policy on it. In identity programmes, it appears when discovery, review, and enforcement are split across different tools or teams, leaving access partially visible but not truly controlled.

What's in the full article

Opal Security's full article covers the operational detail this post intentionally leaves for the source:

  • Jason Fernandes’ direct comments on how Mercari organised its AI Security function and governance structure
  • The team’s practical handling of authentication, authorization, auditing, and tool-control questions across AI use cases
  • The internal split between AI in products and AI in the enterprise, including how consultations are routed
  • Mercari’s forward-looking plans for AI governance, automated inventories, and guardrails for secure AI enablement

👉 Opal Security’s full article covers the governance model, team structure, and AI security practices Mercari is using.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on June 23, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org