Three enterprise AI security products launched in a 48-hour window this week. Aurascape dropped its Zero-Bypass MCP Gateway. PointGuard AI shipped its MCP Security Gateway. Proofpoint extended its AI Security platform to cover MCP connections.
Gartner is already recommending organizations "deploy AI/API gateways or MCP proxies to mediate traffic, enforce policies and monitor agent behavior." The engineering is real. The market timing is right.
And every single one of them has the same structural gap.
They inspect. They monitor. They flag. They route. None of them block a tool call before it executes, with a signed decision, an auditable receipt, and a clear stated reason.
That is the difference between a security camera and a lock.
TL;DR
- Three MCP security gateways launched this week: Aurascape, PointGuard AI, Proofpoint
- They do inspection, monitoring, and policy-based routing. Real value, genuinely useful
- Zero of them implement pre-action authorization at the tool call level
- Inspection is retrospective. Authorization is prospective.
- I'll show you exactly what the missing layer looks like in code
The week MCP security became a product category
The backdrop matters. MCP has 30 CVEs filed in 60 days. 38% of publicly scanned MCP servers have zero authentication. CVE-2025-6514 scored a CVSS 10.0, the worst possible rating. That is why three security products launched in 48 hours. The pressure is real.
Here is what each one actually does:
Aurascape Zero-Bypass MCP Gateway: Visibility into MCP servers and tool calls, testing before release, production guardrails for live AI interactions, detection of malicious activity in tool call traffic.
PointGuard AI MCP Security Gateway: Real-time inspection of prompts, tool calls, and responses. Detects and blocks unsafe instructions based on content analysis. Built for the "shadow MCP" problem where agents run outside centralized governance.
Proofpoint AI Security: Extends across endpoints, browser extensions, and MCP connections. Visibility and control framed as "intent-based detection" of risky AI behavior.
Here's the pattern across all three:
| Aurascape | PointGuard AI | Proofpoint | |
|---|---|---|---|
| Real-time inspection | ✓ | ✓ | ✓ |
| Policy enforcement | ✓ | ✓ | ✓ |
| Pre-action authorization | ✗ | ✗ | ✗ |
| Signed audit receipt | ✗ | ✗ | ✗ |
All useful. None of it is the same as authorization.
The camera vs. the lock
A security camera tells you someone walked into the vault. A lock stops them before they get in.
MCP gateways, as launched this week, are cameras. Extremely good cameras, with AI-powered analysis, policy routing, and real-time alerting. But they observe the tool call. They do not, at the protocol level, block it based on a pre-defined policy tied to the agent's verified identity and the specific resource it is trying to access.
Pre-action authorization works differently. Before the tool call executes:
- The agent presents its identity: an APort passport, a signed JWT, any verified credential
- The authorization system checks: is this agent allowed to call this tool, on this resource, with these parameters, right now?
- A signed decision is issued: allow or deny, with a stated reason and a receipt ID
- That decision is logged permanently to an audit trail
- Only then does the tool call proceed
This happens before the action. Not during inspection of what was requested. Before execution.
What inspection misses
Consider this scenario. An AI agent is running inside your organization. It has been given access to your Slack integration, your GitHub API, and your internal document store. Legitimate tools, legitimate agent.
An MCP gateway with inspection enabled will monitor every call the agent makes. It will flag unusual patterns. If the agent starts exfiltrating data at 2 AM, you will probably get an alert.
But the data will already be gone.
Pre-action authorization would have required the agent to present its identity before accessing the document store at all. The policy says: read access only, business hours, /reports directory only. An attempt to access /internal/finances at 2 AM? Denied before it executes. With a signed receipt that says why.
This is the structural difference. Inspection shows you what happened. Authorization stops what should not happen.
What this looks like in code
Here is a pre-action check from APort guardrails running before a tool call:
# Before any tool executes:
~/.openclaw/.skills/aport-guardrail.sh exec.run \
'{"command":"curl https://internal-api.company.com/export","context":"automated_report"}'
# The guardrail checks, in order:
# 1. Kill switch active? Deny immediately
# 2. Passport valid and active? Deny if expired or revoked
# 3. Policy allows this command pattern? Deny if it matches blocked patterns
# 4. Decision logged with receipt ID? Always.
The response looks like this:
{
"allow": false,
"receipt_id": "d7f2-ab41-9c3e-...",
"reason": "policy block: data export pattern detected outside authorized hours",
"checked_at": "2026-03-18T02:47:11Z",
"agent_id": "agent-passport:prod-worker-7"
}
The receipt ID is permanent. Six months from now, you can reconstruct exactly what the agent attempted, what policy blocked it, and what identity was attached to the request. That is not inspection. That is accountability.
What this is NOT
Pre-action authorization is not a replacement for MCP gateway monitoring. The cameras are still valuable. Real-time behavioral inspection catches anomalies that static authorization policies do not anticipate. They are complementary, not competing.
Pre-action authorization is also not only an enterprise concern. If you are a developer running an agent locally that has access to your filesystem, your email, or your calendar APIs, you have the same structural risk at a smaller scale. Clinejection in February 2026 compromised thousands of developer machines via a malicious package that hijacked coding agents. Not enterprise infrastructure. Individual developer environments.
And pre-action authorization is not about blocking agents from being useful. The point is to define upfront what an agent can do and enforce it before execution, not to prevent agents from acting at all.
The bigger picture
The MCP security gateway launches this week are a good sign. The industry is taking agentic AI security seriously, fast. That is genuine progress.
But I have spent the past year building authorization infrastructure for AI agents, and the pattern I keep seeing is this: industries almost always build the perimeter first. Firewalls, VPNs, network monitoring. Then, years later, interior controls arrive: identity management, fine-grained access policies, signed audit trails.
Agentic AI is compressing that timeline because agents are already in production. The perimeter is being built right now. The interior controls need to come next, not in three years.
Financial systems figured this out decades ago. Every transaction runs an authorization decision: not "did the card work?" but "is this cardholder allowed to make this purchase, at this merchant, for this amount, at this hour?" That pre-authorization step is why you get a fraud alert when your card is used in a different city at 2 AM, not a theft report three days later. Builders in Nigeria, Canada, and every country in between now benefit from that infrastructure without thinking about it.
AI agents need the same thing. The cameras are going in this week. The locks are next.
Over to you
If you are running AI agents in production right now, where does your enforcement actually happen? Gateway inspection, system prompt guardrails, infrastructure sandboxing, or something else entirely?
And if you have tried implementing a pre-action authorization layer for tool calls, what broke first?
Top comments (0)