The rule fires at the moment of the call
ServiceNow's AI Control Tower blog carries a post by Ashley Snyder, headed AI Gateway is back, previewing what ServiceNow says lands on September 10, 2026. The post describes AI Gateway as the runtime enforcement layer inside AI Control Tower, sitting between AI agents and MCP servers and enforcing access policies at the point a tool is invoked. It ships as part of AI Control Tower Core through the ServiceNow Store, existing customers get it with the latest version upgrade, and the post carries a disclaimer that planned features may change.
The phrase we'd circle is enforcement at the point of invocation. Every rule an agent follows today lives in one of two places, a sentence in the agent's instructions or an ACL, data policy, or business rule on the table the tool eventually touches. The gateway is a third place, and the question for a platform owner is which rules move there.
Each layer sees a different part of the request
Take a major incident agent built in AI Agent Studio. It calls a CMDB tool to pull affected services, an incident tool to update work notes, and a chat tool to post a status line to the bridge channel. Three rules apply. Never write to a CI. Never post a customer name into the chat tool. Only update incidents that are already priority one.
The priority rule belongs on the incident table, because a business rule can read the priority field and the gateway cannot. The gateway sees the tool being called, the identity behind the call, and the response coming back, and it has no view of the record. Our piece on why MCP tools still run on your roles and ACLs covers that layer.
The CI rule runs the other way. The record layer cannot tell that the caller was an agent, and on most instances the agent runs under an account that holds the write role anyway. A rule that this agent may never reach the CMDB write tools is a rule about the connection, and the connection is what the gateway governs. The prompt sentence stays as guidance for the model and stops being the control.
Scoped tokens are where the connection rule gets written down
The Control list includes ServiceNow identity authentication with scoped token issuance, and our read is that this is how the connection rule gets enforced. The agent presents a ServiceNow identity and the gateway issues a token scoped to the tools that agent has been approved for. If so, approval in the Govern catalog is the moment a rule becomes real, and the intake form should ask for a list of tools rather than the name of a server.
The post doesn't say how scope is expressed, or whether a token can be limited to one tool on a server or only to the whole server. That is the question we'd put to an account team first, because a per-server scope means the CMDB read tool and the CMDB write tool travel together, and the CI rule above falls back to the prompt.
Blocking a response is the control nothing else could run
Sensitive data detection, which ServiceNow says blocks responses containing sensitive data before they reach the agent, has no equivalent in the older layers. An ACL never inspects what a query returns. An instruction telling the model to ignore card numbers arrives after the model has read them. A filter between the tool and the agent is the only place that check can happen, and in our incident example it is the only control that can stop a customer name leaving the instance.
What the post doesn't describe is what the agent receives when a response is blocked. An agent that gets nothing back may call the tool again, and one that gets an error may tell the bridge the incident tool is down. Whoever owns the agent in production should find out which it is before the control is switched on.
The pause and the scanner both need a name against them
Two more Control items concern the server rather than the call. Tool metadata is scanned at registration so suspicious tools can be blocked before an agent sees them, and any server or tool can be paused instantly, globally or individually, with no code changes. The post says none of this needs instrumentation on the agent side, so it will reach agents nobody has opened in months.
A pause with no code change is a control anyone can pull and nobody remembers to release. Our earlier case for a pause button as an ordinary operating control holds here with one addition. The person who approved a server in the catalog should hold its pause and get paged when its latency, success rate, or connection attempts, the Observe numbers the post lists, go wrong. An approval record with no pause owner is a row in a table.
Draw the rule map before the store upgrade arrives
Pick one running agent and list every rule the team believes it follows. Beside each rule, write which layer can see the facts the rule needs. Rules about field values stay with the record. Rules about which agent may reach which tool go to the gateway, and the approval request for that agent becomes a list of tools. Anything that survives only as a sentence in the prompt gets relabelled as guidance. The same exercise belongs in the design review that sits beside a new agent.
Then ask for the Observe data before anyone asks for a policy. Connection attempts per client shows what each agent is already reaching for, and the gap between that and the approved catalog is the first policy you need. Bring both to the next ServiceNow agent review with one question. If the prompt for your most active agent were deleted tonight, which of its rules would still hold tomorrow morning, and could you point at the layer that held it?
