Should this AI agent take this action right now?

Say you give your support agent access to Gmail because you want it to read incoming messages.

Can it send a reply? Can it permanently delete a thread your legal team needs next week?

Those are three very different decisions. They all go through the same Gmail connection. And once an agent has access, it can make the call without a person sitting there to click the button.

So when the agent asks Gmail to do something, what should happen?

Agen.co’s policy engine answers that question on every tool call through our MCP gateway. We put together five walkthroughs in our demo tenant so you can see what happens when you change the action, the timing, or who’s asking.

What does “give it access to Gmail” actually mean?

In the first walkthrough, we give the support agent an exception for Gmail’s read tools. Delete stays under the baseline policy.

Then we test three calls. Listing messages goes through. Sending asks the user to confirm. Deleting gets blocked.

When the agent makes those calls for real, you can see all three decisions in the live log. That’s the setup we’d want for a support agent. It can read what it needs to do its job, and we can decide separately what happens when it tries to send or delete something.

Watch “One connector, three verdicts” on the policy engine page →

What if the exact same call happens at 2 a.m.?

At 2:14 p.m., an agent exports a Salesforce report for a user. The export goes through.

At 2:14 a.m., it happens again. Same agent, same tool, same user. This time the call lands outside work hours.

The request falls outside work hours, so the policy engine asks the user to confirm on their phone. They see an export they didn’t start and deny it. The log records the verdict, the policy that triggered it, the IP address, and who was acting. You can also use geo-fencing to set rules based on where a request comes from.

The next time that export runs, the engine evaluates it again with whatever context it has at that moment.

When a call gets blocked, can you see why?

Claude Code tries to delete a BigQuery table. It gets blocked. If you’re the person who has to figure out what happened, you can open the call in the log and see the rule that made the decision.

You can also replay the request in Test a call. The engine checks exceptions first, then baselines, then the default. In this case, no exception matches, so the Deny delete baseline decides the call. The engine never reaches the default.

Now change the caller to someone in the data-platform group and run it again. Their exception matches, so the same delete is allowed. You can see exactly what changed between the two runs.

How do you go from “we should block that” to a rule?

Say you want to stop Claude Code from merging GitHub pull requests unless the person using it is on the release engineering team.

You can type that into the Rule assistant the way you’d say it to a teammate.

Don’t let Claude Code merge pull requests on GitHub, except the release-eng group.

The assistant proposes an exception that denies github_merge_pull_request for Claude Code for every user outside release-eng. You can review the proposed rule before you create it. Once you confirm, the next merge attempt that matches the rule is blocked, and the log shows which rule blocked it.

What if nobody wrote a rule for that tool?

In the last walkthrough, a research agent spends the afternoon searching code and running queries. Those calls go through.

Then it starts making calls at 2 a.m. It uses a tool it’s never used before. It tries a bulk export from a network it’s never used before.

Behavior anomaly detection, under Security guardrails, treats each of those as a signal. Each match raises the request’s risk. You decide what to do at each risk level. In our demo, medium risk asks the user to confirm and high risk blocks the call.

The export gets blocked even though there’s no rule written specifically for that tool. When you open the log, you can see which signals raised its risk.

What can the policy engine do with a call?

The walkthroughs show allow, step-up, and deny. There are five possible verdicts.

The policy engine returns its verdict in under 30ms. If the call needs approval, it waits for the approver before it runs.

Where this fits in Agen.co

Discovery shows you which agents are connected. The MCP gateway is where governed tool calls run, across 150+ governed connectors and 1,000+ governed tools. The policy engine decides what happens on each of those calls. All three are generally available.

Watch the walkthroughs →

Have a call you’d want to handle differently depending on who’s asking or when it runs? Book a demo from the policy engine page.