Gemini Semantic Governance Policy Goes to Preview: Runtime Intent Gating for Agent Tool Calls

When a multi-step agent takes an action your user never intended, static access controls are not enough. Google's answer, now available in Public Preview on Gemini Enterprise Agent Platform, is the Semantic Governance Policy (SGP) engine: a runtime intent gate that intercepts every proposed tool call and checks it against both the original user prompt and a set of plain-language business rules before execution.

For teams routing requests across multiple providers, the arrival of SGP changes how you think about enforcement layers — and raises a concrete question for every AI operator: where does runtime semantic governance sit relative to your existing gateway, IAM policy, and prompt-filtering stack?

What changed

Google released SGP in Public Preview on June 29, 2026. It adds a new managed infrastructure component — the SGP engine — that you provision inside your own VPC. After the agent's model returns a response, the SGP engine intercepts each proposed tool call, runs two semantic checks, and either approves or rejects the call before the agent invokes the tool:

1. Intent alignment: Does the proposed tool call match the semantic intent of the original trusted user prompt? A user who asks "summarize my calendar" should not produce a send_email directive — SGP catches that.

2. Business constraint compliance: Do the proposed parameters obey the organizational rules you wrote in Natural Language Constraints (NLC)? Example: "Disallow automated refunds above $75." If an agent receives a $89 refund request and the model directs it to call issue_refund, SGP rejects the call.

Both checks must pass. Either failure blocks execution and logs the verdict for audit.

Key capabilities:

• Natural Language Constraints (NLC): write enforcement rules in plain English; no code changes or redeployment needed
• Layered Intent Gating: operates per tool call, per agent, or globally — granular scoping down to specific parameters
• Agent Skills Lifecycle Governance: controls which skill/tool packages an agent can dynamically load, protecting against supply-chain exploits and context poisoning
• Dry Run Mode: observe verdict logs in Cloud Logging before enforcing on live traffic
• Setup time: approximately 20 minutes for VPC networking and SGP engine enablement

Why it matters for AI engineering teams

Context poisoning is the class of attack where untrusted input (a malicious email, a crafted document, a rogue tool response) overwrites or extends the agent's operating context such that the model issues tool calls the original user never authorized. Prompt scanning tools catch injection text at the input layer; SGP catches the resulting action at the execution layer, even when the model has already been manipulated.

For engineering teams building production agents — customer service bots, internal knowledge workers, coding assistants — this fills a gap that IAM rules cannot. IAM grants permission; SGP evaluates whether a technically permitted action is semantically appropriate given what the user actually asked for. The two layers complement each other.

The table Google published in the docs is useful to internalize:

SGP is not a replacement for any of those layers. It is an additional enforcement point targeted at the specific risk of an LLM directing an agent to misuse a tool it technically has permission to call.

The routing and operator angle

The introduction of SGP is worth tracking at the AI gateway layer for two reasons.

Enforcement is per provider, not per gateway. SGP is a Gemini Enterprise Agent Platform feature — it only intercepts tool calls from agents running on that platform. Teams that route across providers (Gemini, Anthropic, Azure, others) through an AI gateway need to implement analogous semantic guardrails at the gateway level or per provider. There is no universal equivalent across providers yet.

Natural-language policy becomes a routing artifact. When enforcement rules are expressed in NLC rather than code, they become assets you maintain alongside your routing configs. Teams that version-control their routing policy — model preferences, fallback chains, provider priority — should also version-control their NLC constraint sets. Policy drift across environments (dev → staging → prod) becomes a new operational risk.

Dry Run Mode enables progressive rollout. The opt-in observation mode lets you validate policy verdicts against real traffic before enabling enforcement. This pattern is directly analogous to how routing teams use shadow mode or canary routing to validate new fallback rules. The tooling is different, but the operational discipline is the same: observe before enforce.

For teams building on Gemini Enterprise Agent Platform, the decision to adopt SGP now (while in Preview) vs. wait for GA is a trade-off between earlier protection and production stability. Preview-tier SLAs and breaking-change risk apply.

What TheRouter users should watch or try

If your production agents run on multiple providers — Gemini, Anthropic Managed Agents, Azure Foundry, or others — you are currently operating without a unified semantic enforcement layer. That is the current state of the industry: each platform ships its own tooling (Anthropic has been building safety classifiers and managed agent sandboxes; Google now ships SGP; Microsoft has Azure AI Content Safety). No cross-provider semantic policy standard exists yet.

What you can do now:

• Evaluate which agents in your stack pose the highest risk from context poisoning or rogue tool calls (candidates: agents with write access to databases, email, financial systems, or external APIs)
• For agents on Gemini Enterprise Agent Platform: enable SGP in Dry Run Mode against current traffic; observe verdict logs before setting enforcement
• For cross-provider stacks: document your intent alignment controls per provider; flag gaps where no semantic gate exists
• Follow the Agent Gateway codelab and the Governing Agent Skills docs to understand the full SGP integration surface

More background on building governed multi-provider routing architectures is in the TheRouter docs.