April 30, 2026 was the day enterprise AI agent security stopped being a slide-deck topic and became a product category.
Within roughly six hours, three vendors shipped what they each called “runtime protection” for AI agents. Microsoft pushed Agent 365 Runtime Protection into public preview at its spring security event, with general availability slated for Q3 2026 alongside the next Windows Server release. Okta launched Okta for AI Agents as the first commercial implementation of its “secure agentic enterprise” blueprint. Two days earlier, on April 28, Cequence Security had quietly gone GA with Agent Personas in its AI Gateway, giving security teams the ability to scope individual MCP tool calls per agent identity.
Three independent companies, one announcement window, one shared assumption: AI agents need an instrumented runtime around them, the same way containers needed a sidecar for years before service mesh ate the category.
They are correct, but they are only half right. And the other half of the story showed up in the same news cycle, in the form of a Meta incident that nobody is talking about loudly enough.
The Meta permission hallucination
Sometime between April 7 and April 21, an internal AI agent at Meta — operating against production data — was asked an ordinary employee question. The agent’s reasoning step inferred a permission scope that did not match the asker’s actual entitlements. It then translated that hallucinated scope into a perfectly valid backend query. The query returned. The data was sensitive. The agent had not been jailbroken. It had not been prompt-injected in any sophisticated way. It had simply convinced itself that the asker was allowed to see something they were not.
That is the exact failure mode that runtime protection in its current form cannot catch.
Microsoft’s Agent 365, Okta’s agent identity layer, and Cequence’s persona-scoped tool calls are all wrapped around the agent. They observe the agent’s process tree, its outbound traffic, its identity context, and the tool calls it tries to make. They do an excellent job of asking “is this agent supposed to be calling this tool right now?”
What they cannot ask, by design, is “is this specific row of this specific table something this specific user is allowed to see today?” That question lives behind the API. It lives in row-level security policies, in column masks, in the difference between WHERE tenant_id = $1 and WHERE tenant_id = $1 AND department = $2 AND classification <= $3. It lives in the schema, and the schema lives at the database boundary.
A runtime that wraps the agent has visibility into intent. A boundary that wraps the database has visibility into reality. You need both.
Why this matters now: the 48.9% problem
The Salt Security 1H 2026 State of AI and API Security Report dropped the same week and put a number on the gap. 48.9% of organizations are entirely blind to machine-to-machine traffic. They cannot monitor what their AI agents are doing once those agents start talking to internal services. 92% lack the security maturity to defend agentic environments at all.
That number explains why three separate vendors decided April 30 was the day. Runtime protection at the agent layer is the easy half — you instrument the host, you watch the process, you enforce policy on outbound calls. It is the same playbook that EDR ran a decade ago, ported to agent runtimes. Microsoft can ship Agent 365 because Microsoft already ships Defender; the muscle memory is identical.
The hard half is what happens once the agent’s call reaches the data tier. That call doesn’t look anomalous. It looks like an authenticated, parameterized query from a service the agent is supposed to be using. The runtime layer correctly says “yes.” The database layer, in most enterprises, has no idea that the call originated from an agent reasoning about permission scopes it did not actually possess.
Six incidents in two weeks
Foresiet’s April 2026 incident roundup lists six distinct AI-related breaches between April 7 and April 21. The categories are worth pausing on:
- Internal data exposure via agent over-fetching
- Supply chain compromise through MCP server poisoning
- Autonomous malware generation by misused tool access
- Coordinated multi-vector attacks against agent infrastructure
- Model leak fallout into production environments
- Documented AI agent control failures
Look at categories one and six. Internal data exposure and agent control failures are both fundamentally the same shape as the Meta incident: the agent did something it was technically authorized to do, but should not have been allowed to in context. None of the runtime protection products announced this week would have stopped them, because the unauthorized action looked authorized to anything observing the agent from the outside.
This is the essential property of agent-driven systems that the runtime-protection vendors are skating around: an agent’s tool call is the output of a reasoning process that the runtime cannot see into. By the time the call leaves the agent, it looks legitimate. The only place left to enforce ground truth is at the boundary the call hits.
The database boundary as control plane
For the last six months, this blog has been making the same case from different angles: the data tier is becoming the de facto control plane for agentic applications. April 30 is the strongest evidence yet that the industry is converging on this conclusion, even if the runtime-protection vendors won’t say it out loud.
Why does the database boundary work where the agent runtime cannot?
Three reasons.
First, the database boundary sees the resolved call, not the agent’s intent. By the time a query reaches Postgres, the agent has already done its reasoning. The query is concrete. Row-level security can evaluate it against the actual user’s actual entitlements, not against the agent’s belief about those entitlements.
Second, the database boundary is identity-aware in a way the agent runtime is not. When you put a properly designed REST or MCP layer in front of your database, you can carry the human user’s identity all the way through the call chain — even when the agent is the one issuing the query. RLS policies evaluate against current_user, not against “the agent that the human is using right now.”
Third, the database boundary is the only layer that can enforce semantic correctness. A runtime can tell you that the agent called query_customers. It cannot tell you that the agent should not have been allowed to filter by internal_compensation_band for this requester. That distinction lives in the schema and the policy, not in the call itself.
What this looks like with Faucet
The way Faucet is built, this isn’t a future architecture argument — it’s the default posture. When you point Faucet at a Postgres or MySQL or SQL Server instance, the API surface it generates carries the requesting user’s identity into every query it issues. RBAC policies sit at the API boundary. Row-level security sits at the database boundary. The agent never gets to issue a raw query; it has to ask Faucet, and Faucet has to ask the database, and both layers get to enforce.
Here’s the shape of it from the operator’s side. After installing Faucet:
# Connect Faucet to your database
faucet connect add prod \
--driver postgres \
--dsn "postgres://[email protected]:5432/app?sslmode=require"
# Generate the API surface
faucet api generate prod
# Define a role that AI agents must assume
faucet rbac role create agent_reader \
--allow "GET /api/v1/customers" \
--allow "GET /api/v1/orders" \
--deny "GET /api/v1/customers/internal_compensation_band" \
--deny "* /api/v1/admin/**"
# Bind the agent's identity to that role
faucet rbac bind \
--principal "agent:gpt-4o-prod-7" \
--role agent_reader \
--on-behalf-of-required trueThe --on-behalf-of-required true flag is the key piece. Faucet will refuse any request from this agent that does not also carry a verified end-user identity. The agent cannot act in its own name; every call propagates the human asker’s identity to the database, where row-level security has the final word.
When Claude or GPT-4o or your in-house model issues an MCP tool call against this surface, the call arrives at Faucet looking like this:
POST /mcp/tool/call HTTP/1.1
Host: faucet.internal
Authorization: Bearer <agent_token>
Faucet-On-Behalf-Of: <signed_user_jwt>
Content-Type: application/json
{
"tool": "query_customers",
"arguments": {
"filter": "tier = 'enterprise'",
"limit": 50
}
}Faucet validates the agent token, validates the on-behalf-of JWT, looks up the human user’s row-level policies, rewrites the query to enforce them, and only then issues SQL against the database. If the agent hallucinated that the user has access to a column they don’t, the database itself returns nothing. There is no path through this stack where the agent’s confidence overrides the data tier’s truth.
That is the part that runtime protection at the agent layer cannot give you, because runtime protection cannot see the schema.
The pattern Microsoft is missing (for now)
Microsoft Agent 365’s Runtime Protection preview is genuinely useful. The fact that it ships alongside AI Security Posture Management in Defender for Cloud, AI-code scanning in GitHub Advanced Security, and AI Data Security Investigations in Purview means Microsoft is taking the layered-defense argument seriously. The Purview piece in particular is doing some of what the database boundary should do — but only for data that has already been classified and only for surfaces Purview can reach.
The gap is between Purview’s classification layer and the actual operational data plane. Most enterprise data lives in Postgres, MySQL, SQL Server, Snowflake, and Oracle instances that no central classification layer fully covers. The agent’s queries hit those databases through whatever API layer the team built — and in 2026, “whatever API layer the team built” is overwhelmingly hand-rolled, partial, and identity-unaware.
This is exactly the gap the database-API generator category was created to fill. Faucet, Microsoft’s own DAB (Data API Builder), Hasura, PostgREST, and Supabase are all converging on the same shape: a generated, schema-aware, identity-propagating boundary between the application tier and the database. The differences are in how aggressively each one carries identity, how much of the MCP surface they expose natively, and whether they treat agents as a first-class principal type.
When Microsoft GAs Agent 365 in Q3, watch closely for whether they extend Purview’s classification model to cover the database boundary itself, or whether they leave that gap for the data API tier to fill. Either path is workable. Both paths point to the same architectural conclusion: runtime protection is necessary, but not sufficient.
What to do this week
If you’re running AI agents against any internal database — and the Salt report says you almost certainly are, even if you don’t know it — three concrete steps:
-
Audit your machine-to-machine traffic. Find the 48.9% gap in your own environment. Which agents talk to which services? Which of those services talk to databases? You cannot defend what you cannot see.
-
Decide whether your agents act in their own identity or on behalf of users. This is the single most consequential design decision in agentic security right now. Service-account agents are convenient; they are also the substrate that the Meta incident ran on. Move toward on-behalf-of as the default.
-
Put a real boundary between your agents and your databases. Not a thin proxy. Not an MCP server that just forwards SQL. A boundary that knows your schema, carries identity, and enforces RBAC and RLS at both the API layer and the database layer. The runtime protection vendors will sell you the agent-side half. You still have to build, buy, or generate the database-side half.
Agent 365 is genuine progress. So is Okta for AI Agents. So is Cequence Agent Personas. They all close real attack surface.
They just don’t close the surface where the Meta incident actually happened — and that surface, the database boundary, is where the next several quarters of enterprise AI security are going to be won or lost.
Getting Started
Faucet generates a production-ready, identity-aware REST and MCP API on top of any Postgres, MySQL, SQL Server, Oracle, Snowflake, or SQLite database. Schema-aware. RBAC built in. On-behalf-of identity propagation by default. Single binary, embedded UI, no separate runtime to manage.
Install:
curl -fsSL https://get.faucet.dev | shThen point it at any database you already have:
faucet connect add prod --driver postgres --dsn "$DATABASE_URL"
faucet api generate prod
faucet serve --port 8080The MCP endpoint is live at http://localhost:8080/mcp. Add it to Claude or any MCP-compatible agent and start enforcing the database boundary on day one.
Documentation lives at faucet.dev/docs. Source on GitHub. The AI agents your enterprise is running today already need this. Everything Microsoft, Okta, and Cequence shipped on April 30 confirms it.