The gateway was never the whole story.

Seven governance myths enterprise teams still believe, and the identity and action layer the agent era actually needs.

Most existing governance was built for human users. Autonomous agents present their own set of challenges. Policies that assume a person is behind every action, and model-level checks that watch inputs and outputs, do little to constrain an agent taking its own actions inside a live tool.

Through 2028, it is estimated that at least 80% of unauthorized AI agent transactions will come from internal policy violations rather than external attackers (Gartner, June 2025).

IBM scores AI governance maturity on a scale that runs from ad hoc, undocumented practices at the low end up to the two most mature tiers, systemic and innovative, where governance is built into how the company operates rather than sitting in a slide deck. Only 21% of surveyed executives report reaching those top two tiers (IBM IBV, 2024). For most, governance is still catching up to how fast agents are being deployed. 

Gartner projects that over 40% of agentic AI initiatives will be canceled before the end of 2027. The main causes include inadequate risk controls, cost, and unclear value (Gartner, 2025).

Proper AI governance is the route to successful rollouts within your organization. But seven myths still shape how most enterprises approach AI governance. Some are about the tools people already trust to handle it (like a gateway, written policy, or monitoring dashboard). 

Others are about what counts as an agent's identity. 

The rest are about timing and scope, whether governance can wait until after you scale, or applies only if you are heavily regulated.

Myth 1: "Our MCP Gateway Governs Our Agents"

An MCP gateway (the Model Context Protocol standard that connects agents to tools) governs the connection layer. That covers which tools an agent can reach, at what rate, under what cost budget, and through which provider. 

But it does not govern the action layer (what the agent does inside each tool once the connection is established).

When an agent connects to Salesforce through an approved MCP gateway, the connection is governed. How much of what happens next is governed depends on the gateway, the MCP server, and Salesforce's own permission model, and many setups stop at the connection. 

What the agent does inside Salesforce after that point (which records it reads, whether it exports contact lists, whether it modifies or deletes objects) is below the gateway's visibility horizon.

A support agent approved to "connect to Zendesk" can often read far more tickets than its current task needs, depending on the OAuth scope and the application's own roles. A sales enrichment agent approved to "connect to Salesforce" may be able to export far more of the contact database than the workflow needs, depending on how its access is scoped.

Action-level governance answers the harder question, defining what an agent can do once inside a system like Salesforce. With action-level governance, agents can be limited to reading contacts, creating activity logs, exporting lists, or deleting records. 

These permissions work best when they are tied to a governed identity (an employee's for delegated work or a managed machine user for automation) so the agent inherits its access from that profile. 

Importantly, the policy should be enforced at execution time on each individual operation, so risky actions are caught and blocked before they happen rather than only recorded in logs.

The right architecture uses both an MCP gateway and action-level permissions tied to employee identities & permissions. 

An MCP gateway handles connection control, and an identity and access layer handles action governance. 

Where MCP gateway controls stop short is that a connection-layer gateway leaves much of what an agent does after it connects ungoverned. That is the gap an identity and access layer closes.

Myth 2: "API Keys Are a Valid Identity Layer for AI Agents"

API keys identify the application rather than the person. A shared or unmanaged service account typically has no named human behind it. It won’t automatically update its permissions when an employee changes roles or leaves. And when an auditor asks who authorized an action, there is often no clear answer.

For every human identity in the average enterprise there are 45 non-human identities, meaning service accounts, API keys, and machine credentials rather than people, and up to 144 in cloud-native environments (Cloud Security Alliance, May 2026). Every AI agent provisioned with a service account adds to that difficult-to-govern surface. 

Every era of enterprise computing got its own identity layer. On-prem had Active Directory, SaaS had Okta, and AI agents are still waiting on a mature market for their solution, which is the gap Willow fills.

When an agent inherits a real employee's identity through Willow's identity and access layer and your existing IdP (Okta, Entra ID, JumpCloud), it carries that employee's group memberships, role assignments, and permission scope into every tool it touches. Change the employee's role, and SCIM updates the agent's access automatically. Offboard the employee, and the agent loses access in the same event.

SOC 2, GDPR, HIPAA, and, for high-risk systems, the EU AI Act each push in the same direction. Each is looking for logged actions that trace to an accountable identity, though the specific obligation differs by framework. An anonymous service account cannot meet that bar. But an identity inherited from your IdP can.

Myth 3: "A Written AI Policy Is Enough"

A policy document defines intent. It might say an agent can read customer records but never export them, or open a support ticket but never close one. Maybe those rules even make their way into system prompts for AI chatbots or agents. 

But governance means enforcing that intent at the moment of execution, on every action, instead of trusting the agent to stay inside the lines of policy documentation.

Almost every enterprise has a governance framework written down somewhere. Most of those frameworks were built before agents, and 77% report that AI adoption is already outpacing their governance capabilities (IBM, June 2026).

A policy document alone will never be able to catch up to AI adoption because it cannot:

• Produce an audit trail for a SOC 2 review.
• Stop an agent from reading records it was never supposed to access.
• Prevent a misconfigured workflow from writing to the wrong data objects.
• Detect the moment a deployed agent starts behaving outside its permission profile.

To catch up, and even get ahead of AI adoption, organizations need runtime enforcement operating at the execution layer. 

When an agent makes a tool call, the governance layer verifies identity, checks the action against scoped permissions, and either approves or blocks the call before it executes rather than after the fact. 

The result is that an agent can only do what it has explicit permission to do, and that gets checked on every call rather than assumed from a document.

Policy documents belong in any governance program. They describe what an agent should and should not do. But it is the technical system that must then put that into force, checking each action as it happens and blocking anything the policy did not allow. 

When the written policy and the runtime checks match, agents stay inside the rules the policy set. 

But when the policy sits on paper with nothing enforcing it, an agent can do whatever it wants inside a live tool and no one finds out until later.

Myth 4: "Monitoring Covers Our Compliance Requirements"

Operational monitoring answers "did the agent run and complete successfully?" 

Compliance audit trails answer “What did the agent do, on which records, under whose authority, at what time?”

SOC 2, HIPAA, and (for high-risk AI systems) the EU AI Act expect audit evidence at the action level, deeper than the connection level.

A gateway log that records "Salesforce API call from Agent X at 14:32:07" does not satisfy a compliance request for "show me every customer record that agent accessed last quarter." 

An action-level audit trail records the call, specific record object, action type (read, write, delete), data scope, and the human identity that authorized the agent's session.

That question stumps most teams today. Only 28% can reliably trace agent actions to a human or system across all environments (Cloud Security Alliance / Strata Identity, February 2026). 

And the pressure to close that gap is no longer coming only from security teams. Regulators have started to demand it too. 

The EU AI Act's record-keeping duties for high-risk systems call for that same traceability to an accountable human identity, which connection-layer logs cannot produce.

Continuous compliance monitoring usually runs on infrastructure tools like Splunk, Datadog, and Grafana. Those tools are good at system-level telemetry, things like error rates, latency, and which service called which. Without an identity & access layer they cannot capture the actual work an agent did, i.e. "Agent Alpha created issue PROJ-422 in Jira as Sarah.Chen, priority High, from workflow W-0041." 

That is the detail Willow's governance and compliance layer is built to produce.

Without it, when an issue surfaces (usually at the first SOC 2 audit or regulatory inquiry after deployment) someone has to reconstruct what already happened. Every action an agent took before governance was in place must be pieced back together from connection logs that never recorded which person was behind each call. That work is slow, expensive, and sometimes simply impossible.

Myth 5: "We Only Need AI Governance If We're in a Regulated Industry"

The EU AI Act's Article 50 transparency obligations apply from August 2, 2026, and the Commission's enforcement powers over general-purpose AI providers begin the same month (EU AI Act, Regulation 2024/1689). 

The Act is not limited to regulated industries. It can reach providers and deployers inside the EU, and some outside it, when they place systems on the EU market or their output is used in the EU, with duties that depend on the system's role and risk classification. 

The law is not the only pressure. The NIST AI RMF and ISO/IEC 42001 now show up in enterprise due-diligence and procurement questionnaires, especially in financial services, healthcare, and government buying. NIST asks you to govern, map, measure, and manage AI risk across a system's life, and ISO/IEC 42001 certifies that you run a documented AI management system with owners and a review cycle. For a growing set of buyers, being able to answer for your AI governance is turning into a precondition of the deal. 

Regulation is not the only reason to care, either. The simplest and most straightforward reason to care is that improperly governed AI creates significant business risk. 

An agent running under anonymous credentials inside a mid-size SaaS company's Jira and GitHub is the same attack surface as one inside a regulated bank. If it leaks a customer list, wipes a repository, or corrupts production data, the company has a breach to disclose, costs to pay, customers to win back, and a board asking how it happened. None of which depends on being regulated.

Grip Security reports that AI-related SaaS attacks rose nearly 490% year over year (Grip Security, 2026). The weaknesses behind AI systems that are often exploited include stale credentials, over-permissioned agents, and shadow AI. These show up in companies of every kind and are not limited to regulated industries. 

Myth 6: "We'll Govern Agents After We've Scaled"

Almost three quarters (74%) of enterprises expect at least moderate agentic AI use within two years, up from 23% at that level today (Deloitte, State of AI in the Enterprise, 2026).

AI use is only going to grow. The cost of retrofitting governance rises with every agent deployed without it. Every ungoverned agent adds to a growing pile of credentials no one has reviewed and actions no one can fully reconstruct, with permissions that were handed out without anyone checking what the agent actually needed. 

The audit work scales with the total number of agent actions taken without attribution, not just the count of agents deployed.

When an agent misbehaves or is compromised, the organization that governed from day one can identify it, scope the blast radius, and use a kill switch to revoke any agent or tool across the org instantly. Yet 35% of executives say they could not immediately shut down a rogue AI agent (Writer, 2026). 

Governance built on identity and access lets you scale AI with confidence. Every agent inherits the permissions an employee already has, so you are not building and maintaining a separate access system or set of rules. On their own, the access controls you already trust do not reach AI agents. A governed identity for each agent, whether a delegated employee or a managed machine user, extends those controls to what the agent does.

Putting that foundation in early is a small, fast piece of work. With a platform like Willow, an agent picks up its identity from your existing IdP and its permissions are scoped before it ever runs. A complete access and permissions system, as well as full audit trail, all established from the first action. That is a modest cost at deployment, and saves the much larger one of untangling a year of ungoverned activity later. That’s not even to mention the issues and risk exposure avoided in that time. 

The practical payoff is that security can sign off once instead of reviewing every new use case. As a result, adoption speeds up and the day-to-day runs with fewer surprises. You also cut two kinds of risk at the same time, the business risk of a breach and the regulatory risk of a compliance gap.

Myth 7: "AI Governance Slows Down AI Adoption"

Enterprise AI adoption stalls when security teams cannot say yes. An organization without action-level governance leaves security and compliance holding a question they cannot answer cleanly. How do you scope the risk of an agent when you cannot audit what it does after deployment?

The default answer becomes "not yet" or "only in this controlled environment," and the agent pipeline slows to the speed of manual approvals.

Organizations that deploy an AI governance platform are 3.4 times more likely to achieve high governance effectiveness (Gartner, 2026), and companies with a formal AI strategy report successful adoption at 80%, versus 37% without one (Writer, 2025). Governance lets AI adoption scale.

At Wix, Willow governs roughly 5,000 weekly active users across about 600 governed tools and MCPs, with 300,000+ governed tool calls per week (Wix case study). "We are six to ten months ahead of most companies in AI adoption. More code to production, fewer incidents, real outcomes," says Asaf Yonay, Head of AI Core at Wix.

The same work (identity and access) that satisfies a security review is the work that facilitates AI deployment.

How to Evaluate an AI Governance Platform

Each of the seven myths maps to one evaluation criterion below. When you assess a platform, check whether it addresses every layer. 

The questions that separate real governance from connection-only tooling all start after an agent connects to a tool. 

‍

1) What stops it from taking an action outside its task? If the answer is that the vendor logs everything for you to review later, that is detection, not enforcement. 

‍

2) Whose identity does the agent act under? An agent on its own service account has no tie to a real person, so when that person changes roles or leaves, its access keeps running untouched. What you want instead is an agent bound to an employee's identity through your IdP, with access that ends the moment the employee is offboarded.

‍

The remaining questions are about proof and reach. A platform built for this can produce an action-level audit export for SOC 2, GDPR, ISO 27001, and HIPAA on request, rather than leaving you to pull and format raw connection logs. It should also hold up outside SaaS, keeping its full feature set self-hosted, on-prem, or air-gapped, and its discovery should reach past the agents and MCP servers you already know about to the skills and plugins you do not. 

‍
How far down the table you need to go depends on what you have to answer for. If you only route model or tool traffic, connection-layer tooling is enough. The moment you need to say what an agent did inside a tool, on which data, and under whose authority, you need the action and identity layer.

The right buying criterion is whether the platform closes the action-governance gap, the distance between "can this agent connect to our tools" and "can this agent be held accountable for what it does inside them."

Willow: The Identity and Access Layer for AI Agents

Willow, the Agentic Access Platform, was built to answer every one of those questions with a yes.

Willow provides the identity and access layer, where each agent carries a governed identity through your existing IdP (an employee's for delegated work or a managed machine user for automation), draws on a governed marketplace of 1,000+ integrations, gets action-level permissions scoped per tool, and leaves a full audit trail.

Its shadow-AI discovery reaches past unapproved agents and rogue MCP servers to the unapproved skills and plugins where shadow AI increasingly hides. That works through endpoint sensors and a browser extension that surface agents, MCP servers, skills, and personal API keys at the point of use, approved or not, so teams can review or block them before they reach production data.

That browser extension, Willow for Chrome, is also where much of the everyday governance happens. It can block an unapproved tool inline and strip PII from a page before an agent reads it. 

With Willow, governance is not one more console someone has to remember to open. Approvals for human sign-off reach people wherever they already work, in Slack, in the Chrome extension, or in-app.

Willow holds SOC 2 Type II, SOC 1, GDPR, and ISO 27001 certifications, plus pre-built HIPAA compliance exports. It can be run self-hosted, on-prem, or air-gapped. 

Willow starts free for up to five users and runs $15 per seat on the Startup tier (Willow pricing).

‍

• IBM IBV AI Governance Report, 2024: https://www.ibm.com/thought-leadership/institute-business-value/en-us/report/ai-governance
• IBM AI Control-Gap Study, June 2026: https://newsroom.ibm.com/2026-06-08-new-ibm-study-finds-cios-and-ctos-face-growing-ai-control-gap-as-enterprise-deployment-scales
• Gartner Agentic AI Projects Forecast, Jun 2025: https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027
• Gartner AI Governance Market, Feb 2026: https://www.gartner.com/en/newsroom/press-releases/2026-02-17-gartner-global-ai-regulations-fuel-billion-dollar-market-for-ai-governance-platforms
• Cloud Security Alliance, The Non-Human Identity Governance Vacuum, May 2026: https://labs.cloudsecurityalliance.org/research/csa-whitepaper-nonhuman-identity-agentic-ai-governance-v1-cs/
• Cloud Security Alliance / Strata Identity, Securing Autonomous AI Agents, February 2026: https://cloudsecurityalliance.org/press-releases/2026/02/05/cloud-security-alliance-strata-survey-finds-that-enterprises-are-in-time-to-trust-phase-as-they-build-ai-autonomy-foundations
• Grip Security 2026 SaaS + AI Security Report: https://www.grip.security/blog/ai-governance-statistics
• Writer 2025 Enterprise AI Adoption Survey: https://writer.com/blog/enterprise-ai-adoption-survey/
• Deloitte State of AI in the Enterprise, 2026: https://www.deloitte.com/us/en/what-we-do/capabilities/applied-artificial-intelligence/content/state-of-ai-in-the-enterprise.html
• EU AI Act, Regulation 2024/1689: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689
• NIST AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework
• ISO/IEC 42001: https://www.iso.org/standard/42001

‍