Policylayer is deterministic enforcement outside the LLM reasoning loop.

What can your AI agents actually do? See every tool your agents can call, the dangerous ones, and the token cost of just starting a session. Then put policy on all of it. policylayer.com/stack-check

What can your AI agents actually do? See every tool your agents can call, the dangerous ones, and the token cost of just starting a session. policylayer.com/stack-check

Anthropic ships Fable 5 with cybersecurity guardrails tuned to <5% trigger rate. That is the right goal for an assistant. It is not a governance architecture. Model-layer controls are probabilistic by design. Enforcement at the transport boundary is not.

Session-scoped MCP authorisation is the right direction. Setting a time-limited grant that revokes when the session ends is strictly better than the shared-credential baseline most MCP deployments still run. But there are two distinct enforcement problems, and session scope only addresses the first one. Connect-time scope: which tools is this agent allowed to invoke at all, during this session? Session grants handle this. Call-time argument inspection: when the agent calls a tool, do the actual arguments fall within policy? Does this refund exceed $100? Is this branch main? Does this SQL statement contain DROP? Session grants cannot answer these questions because they are evaluated at connection, not at execution. Most production incidents don't involve an agent calling a tool it was never authorised to use. They involve an agent calling an authorised tool with arguments the operator never intended to permit. That is the enforcement gap session-scoped auth leaves open.

knocked up a token cost calculator for the MCPs you run - policylayer.com/token-cost

There is a distinction in MCP governance that is easy to miss in most announcements: controlling which tools an agent can call is access control. Evaluating the actual arguments on each call — at runtime, before the call executes — is enforcement. The difference matters in practice. A policy that allows an agent to call stripe.charge is correct for a support agent with a billing mandate. The same policy allows stripe.charge with amount: 50000. The argument value is where the risk is. Prompt injection, a compromised tool response, or a runaway retry loop can all reach valid tools with malicious arguments. Argument-level policies sound obvious in retrospect: allow refunds under $100, deny above $1,000, require approval in between, deny any SQL tool call matching DROP or TRUNCATE, block force-push when branch is main. These rules do not live at the access control layer. They require an enforcement layer that inspects arguments before execution, every call, not just at session setup. The market is starting to frame this distinction explicitly. PolicyLayer has built on it since launch.

The State of MCP Security June 2026. We classified every tool on every Model Context Protocol server we could enumerate from the public registries - 31,000 tools across 2,031 working servers. The data shows an ecosystem that hands AI agents wide, dangerous, and almost entirely unannounced control over the systems they touch. policylayer.com/research/sta…

Trust the policy, not the agent.

30 days later: we re-ran the State of MCP audit. The ecosystem grew 14% in a month. A new #1 riskiest server. 42% of servers can destroy data or run shell commands. policylayer.com/research/sta…

Google shipped a production GCS MCP server this week. The security architecture is worth reading carefully. The release has two modes. Remote: Google hosts the server, IAM controls access, Cloud Audit Logs records every request. Local: you run it, add custom tooling, own the configuration. The interesting piece is the optional content security layer: Google Cloud Model Armor, positioned at the MCP endpoint, scanning for prompt injection, tool poisoning, and malicious SQL or URL injections before requests reach the agent. Read that again. IAM alone is not sufficient. Google is explicitly describing a second, separate control layer for content threats at the request level. This is not unusual. It is the correct architecture. IAM answers: who is allowed to connect. Model Armor answers: does this specific request contain adversarial content. Two different threat surfaces. Two different control points. The gap most production deployments then miss is the third question: even if a request is legitimate and the caller is authorised, does this particular tool call, with these particular arguments, fall within the policy this organisation has defined for this agent? Model Armor does not answer that. IAM does not answer that. Neither knows that this agent should only read from one bucket, or that reads are capped at 1,000 objects per session, or that this particular argument value is outside the allowed range for this grant. Argument-aware policy enforcement is where operational governance lives. The Google release makes the category clearer, not smaller. If you are deploying agents against GCS today, the audit log and Model Armor integrations are worth enabling from day one. For the argument-level policies that sit above them, PolicyLayer handles that layer: policylayer.com/docs