Delegate. Don’t Abdicate.

Why Arbiter Is the Policy Layer Agentic Commerce Is Missing

By LangGuard · June 2026

Agentic commerce is not coming. It is already here.

ChatGPT processes 50 million shopping queries daily. During Black Friday 2025, AI-driven traffic to retail sites surged 805% year-over-year. Shopify reports orders from AI-powered searches grew 15x year-over-year through 2025. McKinsey projects agentic commerce will generate $3 to $5 trillion annually by 2030.

The protocols are live. OpenAI and Stripe co-developed the Agentic Commerce Protocol (ACP). Google launched the Universal Commerce Protocol (UCP) and Agent Payments Protocol (AP2). Anthropic’s MCP provides the connectivity layer. Visa, Mastercard, PayPal, Stripe, Shopify, and Coinbase are all participating. The rails are being laid. The wallets are being connected.

What is not being built: the enforcement layer between user intent and agent action.

The Delegation Paradox

When a user tells their commerce agent “find me running shoes under $150 that arrive by Friday,” they are not giving up control. They are encoding intent and trusting that the agent will honor it. That trust is the foundation of the entire agentic commerce model.

The problem is structural. The protocols define how agents discover products, construct carts, and execute payments. None of them enforce what the agent does between receiving the instruction and executing the transaction. The moment the agent reasons — and before it acts — there is no deterministic enforcement layer. The user has delegated. But there is no mechanism that ensures the agent stays within the boundaries they actually set.

That is the delegation paradox. And it is why user concern about agentic commerce remains high despite genuine demand.

Four Concerns. One Structural Gap.

End-user concern about agentic commerce clusters around four themes. Each one is a symptom of the same missing layer.

Data privacy and misuse. Commerce agents require deep access to user preferences, browsing habits, purchase history, and stored payment credentials. Users are right to be concerned. Every interaction between agents — during negotiation, dynamic pricing, personalization — can expose behavioral signals that reveal sensitive patterns about buying habits, financial position, and personal life. Without a data governance layer, the agent has no constraint on what it shares, with whom, or when.

Algorithm bias and kickbacks. Users cannot see inside the agent’s reasoning. An agent optimized for merchant commissions or platform fees is indistinguishable from an honest one. There is currently no mechanism that enforces an agent’s recommendations against the user’s stated parameters — not the platform’s commercial interests. If the agent recommends a product because the merchant paid for placement, the user has no way to know and no policy that prevents it.

Security and account takeover. The most underappreciated risk in agentic commerce is intent drift: an agent authorized to shop does not mean an agent authorized to do anything in service of shopping. When an agent operates persistently, the risk shifts from credential theft to unauthorized action within a legitimate session. 78% of financial institutions expect fraud to spike from AI shopping agents. And the fraud isn’t only external — a well-intentioned agent making a mistake at machine speed can cause as much damage as a malicious one.

Manipulation by counterfeiters. Just as businesses optimize for SEO, malicious sellers now build AI-friendly storefronts engineered to manipulate agent reasoning. A fraudulent merchant may pass every automated check, offer below-market prices, and look entirely legitimate — until the agent completes the purchase and the payment credentials are harvested. The user delegated to the agent. The agent was deceived. The user pays the cost.

Arbiter: A General-Purpose Policy Enforcement Engine for Agentic Commerce

Today we are announcing Arbiter — LangGuard’s policy enforcement engine for the agentic enterprise.

Arbiter is not a fraud filter. It is not a payment protocol. It is the deterministic enforcement layer that sits between the agent’s reasoning and the action surface — ensuring that every action an agent takes on behalf of a user is evaluated against explicit policy before it executes.

What makes Arbiter different is its scope. It is a general-purpose policy enforcement engine that can implement any governance requirement across the full commerce lifecycle: from the moment an agent is granted delegation, through every discovery, cart, and payment action, to post-purchase workflows and revocation. The protocols define what agents can do. Arbiter enforces what they are permitted to do.

What Arbiter Policies Look Like in Practice

The following are examples of the policy classes Arbiter can enforce. These are not theoretical — they are the controls that turn user delegation from a bet into a contract.

Data access policies

• Agent may only access the user profile fields required for this specific shopping task
• Agent may not share purchase history, preference data, or behavioral signals with third-party merchants during price negotiation
• PII — card numbers, address, government ID — may not be transmitted to any unverified endpoint

Spending and budget policies

• No single purchase above $X without explicit user confirmation
• Category budgets: $Y monthly for apparel, $Z for electronics — agent cannot exceed them
• Velocity controls: no more than N transactions in any 24-hour window
• First purchase from a new merchant requires human approval before payment executes

Merchant trust policies

• Agent may only transact with merchants on an approved list, or meeting a minimum verified-review threshold
• Merchants registered less than 90 days ago: blocked until manually approved
• Price deviation alert: if the agent selects an item more than 20% above comparable market price, escalate before purchase

Action enforcement policies

• Subscription detection: agent may not initiate any recurring charge without explicit sign-off
• Refund and return controls: agent-initiated refunds above $X require human confirmation
• Bias disclosure: agent must surface the ranking basis for any recommendation above a spending threshold

Human authority policies

• High-value gate: any transaction above $X pauses for user confirmation before executing
• Override window: user has a defined window to cancel any agent-initiated transaction after authorization
• Session audit: complete record of every agent action delivered to the user at session close
• Delegation revocation: at any point, the user can withdraw agent authorization instantly. Mid-session. Mid-transaction. Mid-negotiation. Revocation is immediate, enforced, and recorded.

What This Means for Agent Providers and Commerce Platforms

The platforms building agentic commerce — OpenAI, Google, Anthropic, Microsoft Copilot, Amazon — face a trust problem they cannot solve with protocols alone. The protocols define the rails. They cannot enforce what rides on them.

With Arbiter, agent providers can tell their users something they cannot say today: here is exactly what your agent is permitted to do, here is how we enforce it, and here is the complete record of every decision it made on your behalf. That is the trust and safety story that makes users comfortable delegating — not just comfortable enough to try it once, but comfortable enough to make it a default behavior.

For commerce platforms — Shopify, Stripe, PayPal, Visa, Mastercard, Google, Coinbase — Arbiter is the enforcement layer that turns their protocol investment into a governance story. ACP and UCP define how agents transact. Arbiter ensures those transactions happen within the boundaries the user actually set.

The compliance argument is sharpening too. Singapore’s IMDA published the Model AI Governance Framework for Agentic AI in January 2026. The EU AI Act is extending to agentic systems. The Electronic Transactions Association testified to Congress that authorization, consent, liability, and auditability all apply in the agentic context. Arbiter delivers all four — automatically, as a byproduct of enforcement, not as a manual compliance project.

Delegate. Don’t Abdicate.

The user who delegates shopping to an agent is not giving up control. They are encoding intent as policy — and trusting that the policy will be enforced. Right now, that trust is not warranted. The protocols enable the transaction. Nothing enforces the user’s actual intent at the moment the agent acts.

Arbiter is what closes that gap. It is the deterministic enforcement engine that ensures agents act within the boundaries users set — and gives them the ability to revoke that authorization, instantly, at any moment.

Agentic commerce is a $3–5 trillion opportunity. The platforms and providers that build the trust layer will capture it. The ones that don’t will spend it managing chargebacks, fraud claims, and regulatory exposure.

LangGuard just launched Arbiter. If you are building agentic commerce flows on ACP, UCP, MCP, or any agent harness — and you want to show your users that delegation does not mean abdication — we want to talk.

Request access at langguard.ai

Tag: Shopify · Stripe · PayPal · Visa · Mastercard · Google · OpenAI · Anthropic · Microsoft · Amazon · Coinbase

Claude for Financial Services: From Agent Template to Production

Part 1: The Five Layers Nobody Talks About

May 5th. New York City. Andrew Sorkin, Jamie Dimon, and Dario Amodei on the same stage discussing how AI lives in the world of finance.

FactSet dropped 8%. Morningstar fell 3%.

Wall Street heard “ready-to-run agents.” Nobody asked what it takes to safely build and operate them.

What Anthropic launched

Anthropic launched Claude for Financial Services — five agent templates for the most time-consuming work in financial services: GL reconciliation, KYC screening, month-end close, statement audit, and valuation review.

The event was invite-only. The audience was the who’s who of financial services. The message was clear: AI agents are ready for finance.

Anthropic called these templates starting points.

They are right. And that is the problem.

What the templates actually ship

Each template packages three things:

• Skills — domain knowledge telling Claude how to think about GL reconciliation, how to approach a KYC file, how to run a month-end close checklist
• Scaffolding — a system prompt and agent structure
• Tool contracts — abstract namespaces like mcp__internal-gl__* that say “I expect a GL server to exist here”

That reasoning is genuinely valuable. It encodes months of prompt engineering for workflows that take years to understand deeply.

But Anthropic’s own README is explicit: “does not post to a ledger… every output is staged for human sign-off.”

Staged by whom. Enforced how. That is what the templates do not address.

The map

Insert ??? table visual here

One green column. Twenty-five red question marks.

That is the gap between a Claude agent template and a production-ready financial agent in a regulated institution.

Safe production in a regulated institution demands five layers every institution must have:

L1 — Data layer

There is no live connection to SAP, NetSuite, Oracle, or any system of record. The templates define tool contracts and expect the enterprise to wire real MCP servers to them.

L2 — Tool layer

Every tool the agent invokes needs to be classified before it touches production. What is the risk level? What compliance regimes does it trigger — SOX, GDPR, BSA/AML, SOC 2? What action pairs create Segregation of Duties conflicts?

L3 — Authorization layer

Who and what is permitted to act in this workflow? The GL agent that identifies breaks cannot approve its own correcting entries. That is SoD — and it applies to agents exactly as it applies to humans. There is no policy engine in the template. No enforcement mechanism.

L4 — Human authority layer

Anthropic mandates human sign-off. The template provides no mechanism to enforce it. Staging without enforcement is advisory, not operational. Production requires explicit human approval gates — enforced, not suggested — for every irreversible, destructive, or high-risk action.

L5 — Deterministic execution layer

The last mile. No probabilistic action should pass this gate. Every action needs an authorization basis — who sanctioned it, under which policy, what the evidence is. That evidence is what your SOX auditor will ask for. It needs to exist before the action executes, not after.

The road ahead

Taking any one of these agent templates from starting block to production in a regulated financial institution is not a straight road.

It is I-90 in January.

Boston to Seattle. 3,300 miles. 13 states. Each layer is a state you have to drive through.

This is not a criticism of Anthropic. The reasoning layer is real and valuable. A blueprint is genuinely useful. But a blueprint is not a building.

Who has to build this

The Accentures, KPMGs, EYs, PwCs, Deloittes, and McKinseys in the room on May 5th already know this. For them it is a new engagement pipeline. Every financial institution deploying these templates needs an implementation partner who can deliver all five layers.

For enterprises without that support — the path to production runs through a Big 6 engagement or a team of Forward Deployment Engineers building the harness from scratch.

Either way, it is a long road.

What LangGuard is building

LangGuard is building the safe production blueprint for each of these five agent templates.

We are not waiting for someone else to figure this out. We are mapping every mile — layer by layer, template by template — and publishing it as an open resource for enterprises, FDEs, and implementation partners.

Starting with the GL Reconciler.

👉 Read the GL Reconciler production blueprint: github.com/LangGuard-AI/financial-services

If you are an enterprise evaluating these templates, an FDE building deployments, or a consulting practice standing up Claude for Financial Services — get in the car.

Follow LangGuard. Engage with us. Help shape the recipe.

The road is long. Let’s drive it together.

Up next in this series

Part 2: GL Reconciler — The Production Blueprint

LangGuard · Agentic Workflow Governance · langguard.ai

This post reflects LangGuard’s analysis of the Claude for Financial Services agent templates. It is not legal or compliance advice. Consult your internal audit and legal teams before deploying AI agents in regulated workflows.

The Emergence of Context-Layer Attack Surface

For years, corporate security leaders have invested heavily in building zero-trust architectures designed to verify every user, every device, and every network packet before granting access to internal resources. The fundamental premise of zero-trust is that no entity inside or outside the network should be implicitly trusted. However, the introduction of autonomous agents via modern protocols has created a massive conceptual blind spot within these carefully constructed defenses. When an organization connects an agent to its internal systems, it often implicitly trusts everything the agent is told, creating a glaring contradiction in the zero-trust philosophy.

This blind spot is now widely recognized by researchers as the context-layer attack surface. It refers to the capacity for malicious or manipulated content to flow directly into a language model’s reasoning process, inducing the agent to perform unauthorized operations without any underlying compromise of the model itself or the theft of traditional credentials. The agent simply trusts its context implicitly, executing actions based on poisoned data.

Because these agents typically operate with the full access privileges of the user who originally configured them, a single manipulation can have catastrophic consequences at an enterprise scale. A recent demonstration by Invariant Labs showed that a malicious server could silently exfiltrate a user’s entire WhatsApp message history. The researchers achieved this not by hacking the messaging application, but by poisoning a tool that the agent already legitimately trusted. Once the agent ingested the poisoned context, it autonomously executed the exfiltration commands.

Regulatory Pressures and the Push for Compliance

The escalating risks associated with autonomous systems and the glaring vulnerabilities at the context layer have not gone unnoticed by government regulators. The legal and compliance landscape is shifting rapidly as authorities attempt to establish clear boundaries for corporate responsibility regarding automated decision-making and data handling. Organizations can no longer rely on self-regulation. They must proactively adjust their compliance frameworks to account for the unique challenges posed by agentic software, or face severe penalties. Throughout 2024, a wave of enforcement actions clearly exposed the weaknesses in how businesses were deploying these technologies. Federal, state, and international regulators heavily targeted practices surrounding data retention, third-party data transfers, and consumer-facing notices. Regulators penalized companies for making misleading claims about their automated capabilities and for the unauthorized transfer of personal data to external processing models. The overarching message from these enforcement actions was unequivocal: businesses must take a highly proactive approach to privacy and compliance, or they will face severe legal and financial consequences. Closing compliance gaps before regulators intervene is now a mandatory boardroom priority.

For corporate security teams, the evolution of these regulatory frameworks means that compliance mandates now directly address autonomous systems, requiring continuous observability, centralized activity logging, and real-time alerting across the entire software ecosystem.

Arbiter and SCOPE - Governing the Action Layer.

To operationalize these advanced defensive requirements, the industry requires specialized infrastructure capable of intercepting and evaluating agent behavior at runtime. This infrastructure must bridge the gap between traditional security monitoring and the unique needs of autonomous decision-making. LangGuard has developed two critical components to address this exact challenge, providing the tools necessary to securely deploy agentic workflows in production environments: the LangGuard Arbiter enforcement engine and its complimentary open-source  SCOPE offering.

LangGuard Arbiter serves as a highly advanced enforcement engine designed specifically to govern the actuation layer. While traditional security tools operate at the network boundary, analyzing packets and authentication tokens, Arbiter operates directly at the action layer. It executes runtime policy enforcement at the exact moment an artificial intelligence agent attempts to invoke a tool or modify a system. When an agent requests an action, Arbiter intercepts the request and performs deep semantic validation. It does not merely check if the agent possesses the correct application programming interface key. Instead, it analyzes the context of the request, the history of the session, and the specific data involved to determine if the intent behind the action violates corporate policy. If an agent attempts to execute an action that deviates from its approved baseline behavior, Arbiter can dynamically block the request, preventing the execution of malicious or erroneous commands before they impact the business.

However, securing the action layer is only one part of the enterprise equation. Organizations must also meet strict regulatory and reporting requirements, which is where the SCOPE offering becomes essential. SCOPE - Security, Compliance & Operational Policy Evaluation - is an open-source initiative designed specifically for Model Context Protocol compliance for Claude and other agents. Arbiter and SCOPE are complimentary - while Arbiter handles the active, runtime security enforcement of actions, SCOPE ensures the deployment aligns with governance standards, maintaining the necessary audit trails and compliance documentation required by modern regulations.2

By integrating SCOPE with Arbiter, organizations achieve a complete governance posture. SCOPE allows compliance teams to formally define and document the boundaries of an agent’s operational environment based on user identity and task sensitivity. It ensures that all necessary tracking is in place to satisfy external auditors. If an attacker attempts a context-layer attack, Arbiter stands ready to block any resulting unauthorized tool invocations at the action layer, while SCOPE ensures the incident is logged and mapped to the appropriate compliance framework. This combined approach provides the definitive solution to the zero-trust blind spots plaguing current autonomous deployments. By controlling compliance with SCOPE and enforcing security with Arbiter, organizations achieve the traceability, accountability, and auditability necessary to confidently move their artificial intelligence projects out of the pilot phase and into secure, audited production environments.

Try It Yourself

Together, SCOPE and Arbiter provide the definitive solution for agentic deployments. SCOPE ensures the organization meets its legal and regulatory obligations, while Arbiter stands guard at the action layer, ready to block any tool invocation that violates corporate policy. This combination delivers the traceability, accountability, and auditability that information technology and security leaders demand to approve projects for production. Ready to see how compliance monitoring and semantic validation can protect your agentic workflows? Explore the details and try the new capabilities today by visiting https://scope-mcp.langguard.ai/.

Most teams start their AI journey by playing around with a few personal API keys, but things get messy fast as you start to scale. You often end up with a dozen different models and no clear way to manage them all. This is why an AI Gateway is becoming a standard part of the modern tech stack.

What Is An AI Gateway?

Think of an AI Gateway as a central hub that sits between your applications and your AI models. It ensures every request follows the same rules, regardless of which model is being used. A recent Deloitte report points out that succeeding with AI at scale depends on having an organized foundation to connect and govern these interactions.

Why Use An AI Gateway?

You cannot manage what you cannot see, and in the AI world, this visibility is called observability of inference. Inference is basically the process where an AI takes a prompt and generates an answer. If you have teams across the company using different models, tracking costs and performance becomes a major headache. A gateway fixes this by gathering telemetry, which is just a term for automatically collecting data on how the system is behaving. As the LangGuard blog mentions, having this level of visibility is the only way to move from small experiments to reliable production systems.

Things get even more interesting when you start using AI agents that can actually perform tasks, like looking up data or sending emails. This is usually done through the Model Context Protocol, or MCP. Think of MCP as a universal language that lets an AI talk to external tools in a consistent way. Since these agents have more power to act, you really need to keep an eye on them. An MCP gateway that understands these tool calls keeps a record of every action the AI takes, so you always know why it made a specific decision.

How Gateways Add Enforcement

Watching what happens is a great start, but sometimes you need to step in and stop a mistake before it happens. This is enforcement, and doing it at the gateway level comes with advantages. Instead of asking every developer to write their own security checks, you can set one rule at the gateway level. For instance, you could block any response that accidentally includes sensitive customer data. Analysts at Gartner have noted that this kind of central control is a huge priority for companies trying to balance speed with safety as they grow their infrastructure.

This kind of safety is a big deal when agents have access to your internal systems. If an AI has permission to delete a file or move data, you want a second pair of eyes on that action. The gateway acts as a safety net, checking every tool call against your company policies. This helps avoid accidents and gives you an immutable audit trail. An audit trail is a permanent record of actions that cannot be changed later, which is a lifesaver when you need to prove that your systems followed the rules.

Announcing: LangGuard AI Enforcement

To make all of this easier, we have built a deep integration between LangGuard and LiteLLM. If you are not familiar with it, LiteLLM is a popular tool that lets you connect to hundreds of different AI models through one simple interface. By pairing it with the LangGuard platform, you get a full setup for both watching and controlling your AI traffic. It is an easy way to stay flexible with your model choices without giving up the oversight you need in a professional environment.

Setting up the integration is designed to be as simple as possible. Once you connect the two, LangGuard will automatically find your models, MCP servers, and tools, keeping your AI asset inventory updated automatically as you add new AI assets, so you do not have to spend time on manual updates or spreadsheets to keep track of everything.

The most helpful part of this setup is the automatic guardrails. LangGuard can deploy security policies directly to your LiteLLM proxy so they run in real time. If an AI request looks suspicious or violates a rule, the gateway blocks it immediately. Security is the core focus here, which is why we used a fail-closed design. This means that if the connection between the systems ever drops, the gateway will block AI traffic by default until it is restored - it is much better to have a temporary pause than to let unprotected data slip through. We also added a permissive mode. This lets you test out new security rules by receiving an alert instead of blocking the user, which is a great way to try out a new policy before you fully commit to it.

Bringing Sanity To AI Governance

Combining LangGuard and LiteLLM gives you the infrastructure to build AI applications that are safe and easy to monitor. You can use the latest models while knowing your data is protected and your costs are tracked. Our goal is to help you focus on building great products while we take care of the governance and monitoring. This is a big step toward making AI work reliably for everyone involved in your organization.

How is your organization planning to manage the growing complexity of your AI tool connections this year?

Agents Are Starting to Operate Systems

Over the past few years, AI has primarily generated content. That is changing.

Agents are now operating inside enterprise systems. They write code. Query data. Trigger pipelines. Call APIs. Create databases. We no longer ask AI “what, where, or how.” We now instruct it to execute and take action. AI systems can use tools, read files, decompose problems, and operate directly inside enterprise systems. Interact with SaaS and developer platforms.

Agents Will Proliferate

Enterprises are entering a world where agents will rapidly proliferate. They will be embedded across:

• developer environments
• data platforms
  
  
• SaaS applications
• enterprise workflows
• copilots and automation systems

A single organization may soon run hundreds or thousands of agents. In many environments, agents will outnumber humans. And they will not just observe systems. They will operate them.

Agents Act Through Tools

Agents deliver outcomes through tools — tools already embedded in enterprise environments.

• SQL queries
• APIs
• pipelines
• databases
• SaaS connectors
• cloud resources
• MCP tools

When an agent uses a tool, it is no longer generating text. It is taking action inside enterprise systems. Those actions interact with critical control surfaces:

• data — what is accessed or modified
• identity & permissions — who is allowed to act
• credentials — how actions are executed
• infrastructure — where actions run

Tools turn AI reasoning into real-world enterprise activity.

The Agentic AI Blind Spot

Today, most organizations cannot answer basic questions:

• What data did the agent access?
• Which identity executed the action?
• What tools were used?
• What actions were triggered?
• Which policies governed the workflow?

This is not because enterprises lack governance. They have many systems of record:

• IAM systems
• cloud platforms
• data governance tools
• ticketing systems

But these systems were designed for humans and applications. Not for autonomous agents orchestrating tools across the enterprise. This creates a new operational blind spot: Agentic AI activity without enterprise control.

Every New Layer Requires a Control Plane

Every major computing layer introduced a control plane:

• cloud → cloud control planes
• containers → Kubernetes
• identity → identity control planes

Agentic AI introduces a new operational layer: A layer where agents interact with:

• models
• data
• tools
• infrastructure
• enterprise systems

This layer requires a way to:

• observe
• govern
• control

AI behavior across the enterprise.

Introducing LangGuard

LangGuard is an AI Control Plane designed to help enterprises safely operate agentic workflows in production.

LangGuard provides:

• runtime visibility into AI activity
• policy enforcement across agents, tools, and data
• governance anchored in enterprise systems of record
• continuous monitoring and remediation of agent workflows

This enables organizations to answer a critical question: Why is the agent doing this? If you cannot explain what an AI system is doing, you cannot trust it. And if you cannot control it, you should not run it in production.

A Simple Philosophy

We are launching LangGuard with a simple philosophy: Don’t trust marketing. Try the product.

If you are building or deploying AI agents and want to understand what is actually happening inside your workflows, we invite you to try LangGuard.

Whenever a new tech makes a big splash, the first thing people do is look for reasons to say it is over. It happened with the web, it happened with iPods and then smartphones, it happened with the cloud, and now it is happening with MCP. If you spend enough time in tech circles, you have already heard the cries that “MCP is dead!” ,  or that it will be replaced by the CLI, often with the justification that “openclaw does not use it so why should anyone else!”

But that handwaves the last century of engineering. Change does not happen by deleting the old world and replacing it with a new one overnight. It happens through long, often messy periods of transition where the new has to learn to live with the old. MCP is not actually about code or servers. It is about how machines and humans share space. If we want to understand why MCP is not going anywhere, you don’t have to look any further than the history of the self-driving car.

We have a habit of thinking that if we want a machine to act on our behalf, we should build a separate, perfect environment for it. We think we can just separate the machines from the humans and let them run on their own tracks. But the history of technology shows that this almost never works. The real world is full of people, and if an AI agent is going to be useful, it has to be able to navigate the same tools, websites, and data sources that we use every day.

The Futurama Fallacy and the Dream of Empty Roads

In 1939, at the New York World’s Fair, General Motors built an exhibit that would become the most popular show in the fair’s history. It was called Futurama, and it was a massive, one-acre model of what America might look like in 1960. People sat in moving chairs and looked down at a miniature world that promised a life of leisure and efficiency. The centerpiece of this vision was a network of automated highways where cars drove themselves without any human input. It was the first time the general public was introduced to the concept of self-driving.

The designer of Futurama, Norman Bel Geddes, believed that the secret to autonomy was to remove the human element entirely from the process of driving. In his vision, cars would not have to deal with the unpredictability of human reflexes or the messiness of city streets. Instead, they would run on dedicated motorways where they were guided by radio control and electromagnetic fields. He thought we would build special lanes where cars were locked into a system of buried magnets or metal spikes that kept them centered and moving at high speeds. The cars were essentially on tracks, like a digital train system.

This is the exact same mistake many people make today when they talk about AI agents using CLIs. They assume that for an AI to be effective, it needs its own “empty road” and not have to deal with the messiness that humans bring. But just like the dream of the automated highway in 1939, this vision fails to account for the massive amount of existing infrastructure we already have. We cannot just tear up the digital roads of the world to make room for the robots. The cars have to learn to drive on the roads we already have.

The Mixed Traffic Challenge

The hardest  part of the self-driving car journey has not been making the car drive; it has been making the car drive around people. In the industry, this is known as “mixed traffic.” We are currently entering the “mixed traffic” era of software. For the next decade or more, AI agents and humans are going to be using the same applications. If a human assistant and an AI assistant are both helping a manager book travel, they are both going to be looking at the same flight booking sites and the same internal company calendars. We are not going to move all of that into a hidden machine-only layer because humans still need to see it, verify it, and interact with it. Change does not happen by suddenly cutting off the human interface; it happens by allowing the machine to participate in the human workflow.

This is why the WebMCP and MCP is so vital. It is what  allows an agent to enter the human world with some level of structure. Without it, an AI is forced to interact with a website like a “digital ghost,” scraping the screen and guessing what buttons do based on visual layout. This is slow, expensive, and breaks every time the website updates its design. MCP changes this by letting the application tell the agent exactly what tools are available and what inputs they need, while still maintaining the visual interface that the human user requires. This coordination between human and machine is the key to making AI actually useful in a professional setting, and WebMCP is the fuel that is going to make it go mainstream. Recently, Google introduced an early preview of WebMCP in Chrome 146. WebMCP is a massive shift because it moves the protocol client-side directly into the browser, allowing any website to become its own MCP server without needing a separate backend or a complex server-to-server connection. The browser itself becomes the orchestrator between the human, the website, and the AI agent.

This is the ultimate evolution of the “mixed traffic” solution. It acknowledges that the web is still a place for people, but it adds a layer of structure that machines can use reliably. It eliminates the need for fragile screen scraping and replaces it with a standardized way for an agent to ask the browser, “What can I do on this page?”

The Openclaw Myth and the Freedom of the Terminal

Some folks look at projects like Openclaw and think the MCP is dead before it even started. Openclaw skips the protocol by giving the agent full terminal access and letting it build its own tools on the fly. It is like giving a chef a whole grocery store and a stove instead of a menu. If the agent can just write the code to talk to an API, why do we need a standard protocol? This has led to a few loud voices declaring that the protocol is already dead because the model is smart enough to figure it out on its own.

But this shortcut comes with some heavy baggage that most businesses just cannot carry. Giving an agent full access to a terminal is a massive security nightmare because the agent inherits every permission the user has. On top of that, having an agent build its own tools every time is a waste of energy. It burns through tokens and takes way longer than just using a pre-defined tool that already knows how to do the job.

The final issue is that this build-it-yourself approach assumes the whole world is perfectly documented. Openclaw works great when it is calling a public API with a clean manual, but that is not the actual situation in most companies. Most internal data is trapped in messy, undocumented legacy systems or private databases that don’t have a public help page. Without a protocol to provide that context, the agent is just guessing in the dark. The protocol isn’t a limitation; it’s the map that allows the agent to function in a world that wasn’t built for it.

The MCP Revolution is Just Beginning

MCP is not a passing trend because the problem it solves is not a temporary one. As long as humans and machines share a digital workspace, we will need a way to bridge the gap between human intuition and machine precision. The history of the self-driving car shows us that you cannot just bypass the humans; you have to learn to work with them. You have to build bridges, not just tracks.

By using standards like MCP and WebMCP, we are giving our agents the ability to see what we see and do what we do, but with the speed and efficiency that only a machine can provide. And as we secure these workflows with platforms like LangGuard.AI, we are ensuring that this transition is as safe as it is productive. The road to autonomy is long, but with the right protocol, we are finally headed in the right direction.

A new feature Anthropic recently released called “remote control” marks a major shift in how engineering teams operate. Develoeprs have always used a relatively closed environment. It is a place where code was written, tested locally, and then pushed to a central server. This is no longer true. This new capability, when enabled, changes that dynamic by allowing a developer to start a session on their laptop and then to control that terminal session from any mobile device or a web browser, bypassing existing SASE and DLP protections.

While this is great for productivity, it essentially places a remote shell on every machine where the tool is active. This creates a new path into the enterprise that security teams must understand. If your organization is not monitoring these connections, you are essentially blind to a new attack surface that exists on every engineer’s desk.

Claude Remote Control relies on an outbound connection to Anthropic servers. When a developer starts the remote control process, the local agent creates a reverse tunnel, allowing the tool to function through corporate firewalls and SASE without any manual configuration or open ports. This outbound-only model means a persistent pathway is established from the laptop to a third-party server, and onto a mobile device you have little control over.

Why MDM Is More Important Than Ever

Because the remote control feature allows a phone to command a laptop, the security of that phone is now an extension of the corporate network. If an employee uses a personal device to control their work machine, a compromise of the phone could lead to a compromise of the workstation. The best way to handle this is by using Mobile Device Management to place the Claude application within a secure container on the device that keeps corporate apps and data separate from personal content. This ensures that the sessions used for development are protected by encryption and strong authentication. Using a managed enclave approach ensures that the remote control feature is only used on devices that meet the company’s safety standards.

Managing Claude Code Itself Is Also Critical

The management of the developer laptop is just as important as the management of the mobile device. Organizations on Enterprise plans can use server-managed settings to enforce consistent standards for every engineer. These settings are at the top of the configuration list and cannot be changed by the individual user. This allows a company to disable risky features or create blocklists for sensitive files. For example, you can prevent the AI from reading SSH keys, which are digital credentials used to access servers, or environment variables that might contain secrets. By using these server-managed settings for teams, IT leaders can ensure that every installation of the tool follows the same security rules without relying on manual setup by each developer. Another reason to manage these tools centrally is the ability to collect telemetry data. Claude Code supports OpenTelemetry, which is an open standard for capturing this type of data across different systems. By exporting this telemetry to a central monitoring stack or AI Control Plane, an enterprise can see exactly what is happening across its entire fleet of AI agents. This includes tracking the cost of sessions and the number of tokens being used, as well as what tools and MCP are being called. Monitoring these metrics can help identify unusual patterns, such as an agent that is suddenly reading a large number of files or attempting to access restricted areas of the network.

Managing Claude For Observability and Governance

An AI gateway is a core piece of enterprise AI architecture that acts as a central infrastructure layer for all AI traffic. Using a gateway provides a single, secure entry point where policies can be enforced uniformly. This invisible backbone for AI agents allows for better observability and ensures that every interaction is logged for audit purposes. It also simplifies the networking requirements by centralizing the attack surface and providing a clear path for all AI-related data, and also allows AI agents to route and point to different models without changing the The most advanced way to govern these systems is through an AI control plane. A control plane is a management layer that is responsible for the discovery, policy, and monitoring of all AI agents in an environment. While a gateway handles the traffic, the control plane manages the rules and the state of the AI workforce. It provides a live registry of every agent and tool, which helps IT teams discover unauthorized tools that might be running on the network. An AI control plane can also automate remediation, such as stopping a session if an agent starts acting outside of its allowed boundaries. This level of control is necessary as we move toward a future where AI agents take autonomous actions on behalf of employees.

Conclusion: You Must Accelerate AI Governance Now, Not In Six Months

Ultimately, the goal is to build a governance framework that works at the speed of AI. By using managed enclaves, server-managed settings, and an AI control plane, an enterprise can create a secure environment for innovation. This infrastructure ensures that as developers get more powerful tools, the organization keeps the visibility and control needed to protect its most valuable data. The remote terminal feature is a great example of how development is changing, and the right architecture will ensure that these changes lead to better outcomes rather than new risks.

Model Context Protocol (MCP) is quickly becoming the connective tissue between AI agents and the enterprise. What began as a simple way to expose tools and data to models is evolving into a de-facto execution layer for agentic systems. As MCP servers proliferate across internal tools, SaaS platforms, data stores, and infrastructure APIs, they quietly accumulate authority: the ability to read sensitive data, invoke workflows, and take real-world actions at runtime.

This creates a new class of security risk - not because MCP is flawed, but because it fundamentally shifts where trust, identity, and control live in AI systems. MCP sprawl is inevitable. What’s optional is whether organizations are prepared for it.

To understand the real risks, we draw on guidance from two world-class institutions: OWASP and the Coalition for Secure AI (CoSAI). Each approaches MCP security from a different angle, and the overlap between them reveals what matters most.

Two Complementary Views on MCP Security

OWASP and CoSAI arrive at MCP security from distinct but complementary lenses:

• OWASP approaches MCP security as a lifecycle problem for MCP-enabled systems - focusing on exploitability, agent behavior, prompt and context handling, tool schemas, and dependency risk. Its Top 10 reflects what developers are most likely to build, ship, and accidentally expose.
• CoSAI approaches MCP from an enterprise security and safety perspective - emphasizing identity, trust boundaries, protocol and transport security, supply-chain integrity, and system-level controls for large-scale agent deployments.

Where these perspectives overlap, you see consensus risks - the issues most likely to surface first and cause real damage as MCP adoption accelerates.

Overlapping Threats: The Highest-Priority Risks

When both OWASP and CoSAI independently flag the same issues, those risks should be treated as default security requirements, not advanced hardening.

Identity, Authentication, and Authorization

OWASP (MCP01, MCP02, MCP07) and CoSAI (MCP-T1, T2, T9) converge strongly here.

MCP turns tools into runtime authorities. If identity, tokens, or scopes are misconfigured, agents don’t just read data - they act. Token leakage, improper delegation, and privilege creep become systemic failures rather than edge cases.

Implications

• IT & Security: MCP servers must be treated as first-class IAM objects with lifecycle management, revocation, and audit.

Prompt, Instruction, and Context Injection

OWASP (MCP03, MCP06, MCP10) aligns closely with CoSAI’s MCP-T4. MCP collapses the boundary between data and instructions. Retrieved context, tool schemas, and shared memory can directly influence execution, making prompt injection, schema poisoning, tool poisoning, and context manipulation first-order risks.

Implications

• IT & Security: Treat MCP resources and tool definitions as executable inputs, not passive data.

Supply Chain Risk and Shadow MCP Servers

OWASP (MCP04, MCP09) and CoSAI (MCP-T6, T11) converge on lifecycle and supply-chain concerns.

MCP servers are lightweight, easy to deploy, and easy to bypass centralized review - classic shadow IT, but with execution power. OWASP emphasizes dependency tampering across SDKs, plugins, manifests, and images, while CoSAI frames the same risk through enterprise supply-chain integrity.

Implications

• IT & Security: Discovery, inventory, and provenance of MCP servers are table stakes.

Observability, Logging, and Auditability

OWASP (MCP08) maps directly to CoSAI (MCP-T12).

MCP failures rarely look like crashes. They look like plausible but wrong actions - which makes semantic visibility essential.

Implications

• IT & Security: You need replayability - who invoked which MCP server, with what context, and why.
• Product Engineering: Debuggability and auditability must be designed in from day one.

Input Validation and Command Execution

OWASP (MCP05) aligns with CoSAI (MCP-T3), and becomes more dangerous when combined with instruction-boundary failures (MCP-T4). MCP tools often bridge directly to file systems, shells, APIs, and infrastructure. Inputs generated by agents are still untrusted inputs.

Implications

• IT & Security: MCP servers effectively act as privileged automation endpoints.
• Product Engineering: Treat every MCP argument as hostile - even when generated by a model.

Key Takeaway on Overlap

If both OWASP and CoSAI flag a risk, assume: This will break first - and it will break loudly.

Non-Overlapping Threats: What Each Lens Reveals

The differences between OWASP and CoSAI are just as instructive. They show what each organization optimizes for - and what teams often overlook.

Where CoSAI Goes Deeper: System-Level Risks

CoSAI uniquely emphasizes network isolation, transport security (MCP-T7, T8), and resource exhaustion or cost abuse (MCP-T10). This reflects an enterprise reality: agentic systems often fail economically or operationally before they fail functionally.

Implications

• IT & Security: Zero-trust assumptions, segmentation, rate limits, and quotas are core security controls.

Where OWASP Goes Deeper: Developer Reality

OWASP is more explicit about token handling, tool poisoning (especially schema poisoning), and dependency risk. Secrets leak through logs and examples. Tools are trusted implicitly. Dependencies move faster than reviews.

Implications

• IT & Security: MCP tokens deserve the same rigor as cloud credentials.

The Unifying Insight

OWASP highlights what developers are most likely to ship. CoSAI highlights what enterprises will ultimately be held accountable for. Together, they point to a simple conclusion: MCP servers are runtime authorities. Securing MCP isn’t about checking boxes - it’s about governing how authority is created, delegated, observed, and revoked in agentic systems.

This year, enterprise IT is arguably going to go through the most significant change since the migration from on-premise servers to the cloud. We are moving to a future defined by Agentic AI. These are not merely passive text generators; but are autonomous agents capable of planning, reasoning, accessing corporate data, and executing complex workflows on our behalf. This shift exposes a critical, widening gap in the modern technology stack.

Traditional security tools like firewalls, API gateways, and Identity and Access Management (IAM) systems were designed for deterministic, human-driven interactions. They operate on binary rules: allow or deny. They simply cannot monitor nor govern non-deterministic AI agents that dynamically select tools, query databases, and generate code in real-time based on evolving context.

To bridge this, a new layer of essential infrastructure is emerging: the AI Control Plane. An AI Control Plane is not just a security tool. It is a centralized governance layer that sits “above” your AI infrastructure (your models, gateways, and agent platforms), and “below” your business intent. It connects AI execution to the “ground truth” of your enterprise Systems of Record. Instead of bluntly blocking AI activity, a control plane enables it by answering critical questions in real-time: Who is this agent acting as? What data is it allowed to touch? Is its current behavior aligned with our business policy? Who should approve this?

The Business Case: Governance as an Accelerator

For business leaders, the AI Control Plane is not an insurance policy; it is a deployment accelerator. A pervading myth in the industry is that security slows down innovation. In the context of Agentic AI, the opposite is true. Without a control plane, organizations remain stuck in “pilot purgatory,” afraid to let agents run autonomously because they lack the controls to ensure safety. Leading analyst firms have coalesced around the view that governance is the primary bottleneck preventing AI from moving to production. The consensus is clear: you cannot scale what you cannot control.

Gartner describes this imperative through their AI TRiSM (Trust, Risk, and Security Management) framework. Their research provides a compelling ROI for governance, predicting that by 2026, organizations that operationalize these principles will see a 50% improvement in adoption rates, business goals, and user acceptance. This isn’t just about compliance; it’s about giving the business the confidence to press the accelerator.

Crucially, Gartner reframes the risk profile for enterprise AI. They estimate that through 2026, 80% of unauthorized AI transactions will stem from internal policy violations—such as information oversharing or misguided AI behavior—rather than malicious external attacks. This highlights that the “enemy” isn’t necessarily a sophisticated hacker; it is often a well-meaning employee or a confused agent accessing data it shouldn’t. A control plane provides the visibility to catch these internal missteps before they become headlines.

From Monitoring to Intervention

While Gartner focuses on the ROI of trust, other firms are defining the architectural necessity of a control layer. As agents from diverse vendors begin to collaborate across ecosystems, enterprises cannot rely solely on the agent platforms themselves for governance. Forrester has formalized this market category as the Agent Control Plane. Analyst Leslie Joseph argues that oversight must live “outside the agent’s execution loop” to ensure monitoring and intervention remain possible even when an agent behaves unpredictably.

They identify three functional planes for the AI stack: the “Build” plane (models and frameworks), the “Embed” plane (workflows), and the “Govern” plane (the control layer). Without this distinct Govern plane, enterprises risk creating a fragmented landscape where every agent has its own unique, incompatible security rules.

IDC echoes this call for robust infrastructure, envisioning a next-generation AI control plane that transcends simple observability. They argue for a new class of operational infrastructure capable of understanding the state of each workflow in real-time and enforcing compliance rules dynamically. This shifts the paradigm from reactive “monitoring” (logging what went wrong yesterday) to proactive “intervention,” allowing IT to pause or redirect rogue agents before damage occurs.

The Shift to Agent Operating Systems

As “Agentic AI” scales, the scrutiny from enterprise boards is shifting from “how do we build agents?” to “how do we govern them?” HFS Research predicts that the lack of such control planes will be a primary pain point, creating demand for AI Control Planes that ensure accountability.

They note that intelligence without governance is chaos. As agents effectively become the new “workforce,” managing their lifecycle and permissions becomes as critical as managing human employees. We are entering a phase where the software itself is the manager, and that manager needs a rigid set of operational principles to ensure the digital workforce adheres to corporate standards.

Analyst Predictions and Frameworks

The Data Intelligence Perspective

Ali Ghodsi, CEO of Databricks, anchors his view in Data Intelligence. He argues that you cannot govern AI if you don’t govern the data it uses. Ghodsi advocates for a data intelligence playbook where the Unity Catalog serves as the unified governance layer.

In this model, the control plane is inextricably linked to the data lake; agents are only as safe as the data governance policies that constrain them. He emphasizes that owning the “ground truth” of enterprise data is existential for successful AI adoption. If an agent can access ungoverned data, it can hallucinate or leak secrets, rendering the agent useless for enterprise applications.

Solutions Now: The LangGuard Approach

While the analysts and industry giants debate standards and macro-infrastructure, LangGuard is building a purpose-built AI Control Plane for IT and Security teams to use today. Our approach is pragmatic, viewing the control plane not as a barrier, but as a bridge that connects new AI capabilities to existing enterprise “ground truth” in order to help accelerate AI projects out of pilot to produciton.

LangGuard’s platform operationalizes governance through a distinct lifecycle:

• Discovery & Screening: The system first identifies all AI agents operating in the environment, classifying them as either “Controlled” (managed by IT) or “Uncontrolled” (Shadow AI). It further distinguishes between “Known” agents (identifiable vendors) and “Unknown” entities, allowing IT to immediately revoke access for high-risk shadow agents.

• Provisioning: Once an agent is approved, LangGuard provisions it with specific, policy-driven credentials. This might include requirements for “On-Behalf-Of” (OBO) authentication or mandatory PII masking, ensuring the agent operates within safe bounds.

• Monitoring and Governance: The platform provides deep visibility into agent behavior, recording every action and decision for auditability. This turns governance from a one-time “gate” into an ongoing operational discipline.

Conclusion

The “block-by-default” approach that served security teams well in the past is incompatible with the era of Agentic AI. Blocking an agent often breaks the very workflow it was designed to automate, driving users to shadow IT. The AI Control Plane offers a sophisticated alternative: a way to govern intent, enforce policy dynamically, and provide the evidence needed to trust autonomous systems.

As enterprises move from piloting simple chatbots to deploying agents that plan, reason, and execute real work, this control layer is becoming the most critical piece of infrastructure in the modern IT stack. It is the missing link that allows organizations to embrace the speed of AI without sacrificing the safety of the enterprise.

Autonomy is easy to admire when it works.

Give an agent a goal, access to a few tools, and the ability to reason, and it starts to feel almost magical. It retries intelligently when something fails. It adjusts its plan. It keeps moving forward without needing to be nudged. In demos, this looks like real progress.

Autonomy itself isn’t the problem.

There are many areas where agents should be free to operate. Summarizing reports. Synthesizing information. Exploring hypotheses. Drafting explanations. When agents get these wrong, the cost is usually low and easy to recover from.

Problems begin when the same level of freedom leaks into higher-risk areas. Once an agent can escalate a case, mutate state, or influence irreversible outcomes, the cost of “just trying again” becomes very real.

The mistake teams often make is treating autonomy as binary, either fully allowed or fully restricted. In practice, autonomy needs to be selective.

Why Static Governance Falls Apart at Runtime

Most governance mechanisms operate before execution begins. Policies are written. Prompts are constrained. Tools are allow-listed. Offline evaluations are run. On paper, this all looks sufficient.

In production, behavior is shaped by context. Latency spikes. Partial failures occur. Data arrives late. A retry that made sense once becomes harmful when repeated across hundreds of parallel workflows. Static governance can explain intent. It cannot enforce behavior once conditions change.

This is usually when teams realize that observability alone doesn’t help much. Knowing that an agent entered a loop does not undo the impact. By the time dashboards light up, the system has already drifted out of bounds.

Runtime Governance as Boundary Enforcement

Runtime governance exists to answer a simple but critical question: what is this agent allowed to do right now, in this context?

It doesn’t attempt to control how an agent reasons. Instead, it sets boundaries around what the system is permitted to execute while that reasoning is happening. How long an agent can run. How many retries are acceptable. When confidence is sufficient. When escalation must stop. When execution needs to be handed off to a human.

These ideas aren’t new. Financial systems have relied on similar constraints for decades. What’s new is the need to apply them while decisions are unfolding, not after the fact. That is why runtime governance feels less like policy enforcement and more like boundary design.

Over-Governing Is a Failure Mode Too

There is an equal and opposite mistake teams make.

Faced with risk, some organizations clamp down everywhere. Every action requires approval. Every decision is gated. Every workflow slows to a crawl. Autonomy is reduced, but so is the value agents were meant to provide.

Latency increases. Humans become bottlenecks. Systems become brittle in ways that are harder to predict. Good runtime governance doesn’t minimize autonomy. It places it deliberately. High autonomy where failure is cheap. Tight boundaries where failure is expensive.

That balance is not a compliance checkbox. It is an engineering decision.

Trust Comes From Predictable Failure, Not Perfect Behavior

No runtime governance system makes agents perfectly safe, and that is not the goal. Production systems do not need perfection. They need predictable failure. When something goes wrong, the system should stop cleanly, surface the issue, and leave behind enough context to understand what happened.

Poorly governed systems fail silently and expensively. Well-governed systems fail early and visibly. In fintech environments, that difference often determines whether teams are willing to trust autonomous systems at all.

Closing Thought

The future of agentic AI in fintech will not be defined by how autonomous these systems become. It will be defined by how precisely that autonomy is bounded.

That line between freedom and control is not theoretical. It is where real systems either hold together — or quietly fall apart.