Should this agent take this action, right now?
The usual question is “can this agent use this tool?” Agen.co’s policy engine sits inside the MCP gateway and decides each call: who is asking, what it’s doing, and when. Every call gets one of five verdicts: allow, step-up, human-in-the-loop, mask or deny.
The verdict comes back in under 30ms. A held call then waits for its approver.
“Allowed” covers more than you think.
- GmailYes to reading mail is yes to sending it and deleting it for good.
- SalesforceYes at 2PM is yes at 2AM.
That’s the trouble with allow or deny on a whole tool. The risk isn’t in the tool. It’s in what the agent does with it, and when.
So the decision has to happen on each call, in the path, fast enough that nobody notices. That’s what the policy engine does.
In the path of every gateway call.
The policy engine runs inside the Agen.co MCP gateway. Before a call reaches the app, the engine decides it. Allowed calls go on to the connector. Denied calls stop at the gateway and never reach it. Either way, the call and its verdict are logged.
- AgentCalls a toolClaude Code, Cursor, ChatGPT or your own agent calls the Agen.co MCP gateway, not the app.
- Policy engineReturns a verdict in <30msInside the gateway, before the call goes anywhere.
- ConnectorRuns the callGmail, Salesforce, GitHub or any of 150+ governed connectors.
denyStops at the gateway. The connector never sees the call.
Five verdicts, each with a trigger.
Every call through the gateway gets exactly one: allow, step-up, human-in-the-loop, mask or deny. Each card says what happens and what sets it off.
- allowThe call goes through and gets logged.When: An exception or baseline allows it, like the support agent's Gmail reads.
- step-upThe user confirms before it runs.When: A step-up rule matches, like one on send, or a guardrail fires, like a call outside work hours.
- human-in-the-loopThe call waits for an approver, like the finance team.When: A rule routes it to an approval flow, which sets who approves and in what order.
- maskThe call runs, and sensitive fields are masked before they reach the agent.When: A data protection policy covers the tool, for fields like email, SSN or credit card numbers.
- denyThe call stops at the gateway, and the log names the rule.When: A rule denies it, like the Deny delete baseline, or no rule allows it under default deny.
What a rule can look at.
Who is asking, what the call is doing, and when and where it happens. Rules combine all three.
The person and the agent
Rules target users and groups synced from your identity provider, like Okta, Entra ID or Google Workspace. When someone changes teams, their permissions follow them. Rules can also target the agent itself: Claude Code, Cursor or your registered agents.
The operation, not just the tool
Every tool is tagged with its operation: read, create, update, delete, send or export. Rules key on the tag, so one baseline, Deny delete, covers every delete tool on every connector. Exceptions narrow it to specific tools.
The context of the call
Security guardrails add IP restriction, geo-fencing, work hours and allowed agents. Behavior anomaly detection flags calls that break an agent's usual pattern: request spikes, unusual tools, off-hours activity, new locations and bulk data access.
One call at a time.
Same connector, three verdicts.
Gmail has tools for reading, sending and deleting. Add an exception so the support agent can use the read tools, and leave delete under the baseline.
Test it: listing is allowed, sending is a step-up and deleting is denied. Then watch the same three calls arrive in the live log.
Allowed at 2PM. Stepped up at 2AM.
A Salesforce export at 2:14 in the afternoon is allowed. The same export at 2:14 in the morning falls outside work hours, so it's a step-up.
The user gets asked on their phone, didn't start it, and denies it. The log keeps the verdict, the policy behind it, the IP and who was acting.
- Work hours
- Geo-fencing
- User and group
- Agent
- Tool
Three layers. Default deny.
Default access is the bottom layer. Set it to deny, and a call no rule allows is denied. Baselines sit above it as broad guardrails on an operation, like Deny delete. Exceptions sit on top, scoped to specific tools, and always win.
- Exceptions
- Baselines
- Default deny
Open a blocked BigQuery delete and you get the rule that decided it: no exception matched, so the Deny delete baseline did. Replay it in Test a call as a data-platform member, and their exception allows it.
Say it. Review it. Ship it.
Tell the Rule assistant what you want: "Don't let Claude Code merge pull requests on GitHub, except the release-eng group." It proposes an exact rule for you to review.
Create it, and the next merge attempt through the gateway is blocked, with the new rule named in the log.
Same agent. Same tool. A different verdict.
A procurement agent buys ten design seats on Stripe. Allowed, no waiting. Then it tries the annual contract with the same tool, and the call stops and waits.
A finance approver gets it on their phone and approves it. Both calls end up in Monitoring next to each other, with their arguments and their verdicts.
Nothing stops silently.
A deny isn't a dead end.
A denied user can request access to the exact tools they need, with a note. A reviewer approves it for that user, or turns it into a policy so the next person doesn't have to ask. Default deny, without the ticket queue.
Every call, every verdict, every rule.
Monitoring logs each gateway call with its verdict, the rule that decided it, the agent, the user, the IP and the raw arguments. Policy changes land in Audits. Stream both to Datadog, Splunk, EventBridge, Sumo Logic, Coralogix or a webhook.
One engine, three teams that need it.
Every call tied to a person and a rule.
Each verdict names who was acting, which agent and which rule decided it. With default deny, nothing runs unless a rule allows it.
Denies you can trace and replay.
Open any deny, see the rule behind it, replay it in Test a call and change who's asking to see exactly what changes.
Say yes without a blanket grant.
Allow an agent's reads, step up its sends and keep deletes behind a baseline, instead of a yes to the whole app.
Walk through the policy engine on a demo tenant.
Give Gmail’s tools their own answers, see the same export at 2PM and 2AM, trace a deny to its rule, write one in a sentence and open a held payment. Click through it yourself.
Five walkthroughs, one question.
Short narrated walkthroughs on our demo tenant. Each one follows a real flow in the product.
Discovery, the gateway and the engine.
Discovery shows you which agents are connected. The MCP gateway is where their calls run, and the policy engine decides each one. Both are generally available.
Can it use the tool? Sure. Should it take this action?
See the policy engine decide on calls like yours, in under 30ms.
Protected by reCAPTCHA. The Google Privacy Policy and Terms of Service apply.
- 01Bring your agentsTell us which agents and tools your teams are connecting.
- 02See calls decidedWatch calls like yours get allow, step-up, human-in-the-loop, mask and deny verdicts.
- 03Trace any verdictOpen a decision and see the rule behind it.