Security in the Loop, Not in the Way: Guiding What AI Agents Do

In your org, a developer is about to open a pull request, but their coding agent decides to publish its working plan as a public GitHub gist first, internal file paths included. A few days later, another agent testing how a webhook works in your code sends a file of real customer records to an endpoint nobody on the team has heard of. Neither agent was attacked. Rather, each one was trying to finish the task it was given, and took the shortest path it could find.

The first problem is finding out. Nothing failed and nobody was hacked, so nothing raised an alarm. At many companies this is probably happening already, and nobody knows. If you're lucky, someone spots the gist or the strange endpoint later. Once you do, your first move as a security engineer is to make sure it can't happen again. So you open a tool you already have, like an MCP gateway, and write a rule. Block that endpoint. Block that kind of upload. Done.

Every block rule has a cost

A block rule written after one incident is aimed at the last thing that went wrong. It often catches more than that, including work that was fine.

Each time it does, someone's task stalls. They have to notice, work out which rule fired, and ask security for an exception. Security then has to decide whether the rule was too broad. And that happens again every time the rule blocks something it shouldn't.

Agents add a cost of their own. When an agent hits a block it doesn't understand, it doesn't always stop. It may try a workaround or make up an explanation, and the rest of the session gets less useful.

A few rounds of it and the rule gets loosened, or quietly turned off, and you're back where you started.

Before you write the next block rule, ask whether you need to block at all.

Guide the agent, not the person

Unlike a person, an agent will take new instructions in the middle of a task. If you tell a person "don't do that, do this instead" while they're working, you've interrupted them. If you tell an agent the same thing, it can take the safer path and keep going.

That changes the job of a security policy. It can guide the agent the moment it acts.

This is how we think about security for agents at Manifold. We want security to know what happened, and also to stay in the loop and guide agents toward secure approaches across the whole organization. That covers every team running agents, not just developers.

Blocking still has its place, as one response among several that you choose on purpose.

The range of responses

A Manifold policy can respond to a risky agent action in several ways. Here they are from lightest to strictest. There's also Disable, which switches a policy off.

Ask is for the calls a person should make, and Neal covered it in his post on Ask. This post is about the cases where nobody needs to decide. With Advise and Correct, no one has to step in, and the agent still ends up on the safe path.

Example: An agent writes a script that uploads log files to a public gist

Northwind and Larkspur are fictional companies.

Background

An engineer at Northwind, a SaaS company, asked their coding agent to pull the logs for Larkspur, one of Northwind's customers, and get them to the integrations team to troubleshoot an issue. The agent pulled the last 24 hours of webhook logs from Larkspur's production tenant into /tmp/larkspur-webhooks.log, and it needed to get them to the integrations team so they could debug the failures.

What the agent tried

The agent decided the quickest way to share the log was a GitHub gist link the team could open from Slack. The agent tries to create the Gist via the corporate Github MCP but is blocked because the MCP does not allow Gist. So to bypass this the agent ran the github cli directly:

The issue

Because the agent leveraged the Github CLI, it is able to bypass this restriction. --public makes the gist readable by anyone and lists it in GitHub's public feed, which bots crawl for leaked data. The log was Larkspur's data, not something that should be exposed publicly. Every failed delivery was logged with its full payload, and those payloads were order events for Larkspur's own customers: names, email addresses, phone numbers and shipping addresses. If the script had run, Northwind would have published personal data belonging to Larkspur's customers under the developer’s GitHub account.

Why a block rule would hurt

The obvious rules are all too blunt. Users and Agents have good reasons to call the Github CLI, so blocking this utility isn’t an option. Blocking api.github.com breaks pushes, pull requests, CI checks and half of what the agent was set up to do. Even blocking gists entirely only moves the problem.

The policy that matched

Correct Public Gist, running in Correct mode. It denies scripts and commands that send file contents to public destinations, such as public gists and paste sites, and returns the safe form for the agent to retry.

Manifold catches this where EDR can't because it sees the tool call itself, before anything runs: the full text of the script, including the destination and the public flag, the task the agent was given and where the file came from.

What the agent received

The policy stopped the script before it ran, so the gist was never created. Instead of a bare refusal, the agent got this message back:

Denied. Customer tenant data can't be posted to public gists or paste sites, which are crawled within minutes (Company Data Handling Policy). Put the file on the internal file share at /Volumes/eng-share/ instead. Share the path, not the contents.

What the agent did next

It dropped the gist and copied the customer webhook log to the internal file share, in a folder for the incident. The policy didn't fire again. The agent posted the file's path in the integrations team's Slack channel, and the team had what they needed to start debugging. Larkspur's data never left Northwind. The agent's summary to the developer said why the gist had been stopped and where the log went.

What security saw

The console recorded one finding, already resolved. It showed:

• who and where: the developer, their laptop and the agent
• the full script the agent tried to run, which EDR never had
• the customer log it would have read, and the public gist it would have created
• the policy that matched, Correct mode, and the standard it enforces
• the denial message the agent received
• what the agent did next: the copy it put on the internal file share

When you do need to stop

Sometimes guiding the agent isn't enough, because the agent itself can't be trusted anymore. Two signs of that are a suspected prompt injection and repeated attempts to reach credentials.

That's what Block session is for. It stops the risky action and everything after it in that session. To carry on, the person working with the agent starts a new session.

Keep this for a small set of strong signals. Used everywhere, it brings back the same cost as a block rule.

What security sees, whatever the response

Every response except Disable records a violation, so security gets one history across all of them. A rule set to Advise shows up in the same place as one set to Block session. You can see what agents tried, how often, and which rules are doing the most work.

That's what keeps security in the loop even when nobody was interrupted.

Where to start

Start by finding your use cases. Make a list of what you block today, in any tool. For each item, ask two questions:

• Is there a safe way to do this that the agent could be pointed to instead? If so, try Correct or Advise.
• Is this a call a person should make? If so, try Ask.

What's left after that is your real block list. It will probably be shorter than the one you started with, and every rule on it will be one you meant to keep.

Most of the time, the agent corrects course on its own, and nobody's work stops.