Blocking is the only answer most security tools have. "Ask" lets the developer decide.

"Ask" is now a policy response on every coding agent we support

An agent runs with the developer's own access, and it treats reading a credentials file like reading any other file. That read is one call among dozens, finished before anyone scrolls back through the summary. Some of those calls are worth recording. A few, like data leaving the company, are worth blocking outright, though block the wrong one and you stop a developer doing their job. Then there are the unusual ones, where it depends on what the agent is about to do, and the developer decides whether to approve or reject it.

Blocking used to be the answer to all three. In our conversations with security teams this year the appetite for it has dropped, because the person a bad block lands on is a developer, the group with the deepest access and the least patience for a rule that stops their work. Agents already stop to ask for things, so one more question mid-task does not feel like a block.

One team wanted unusual actions confirmed rather than blocked. Another wanted a check on long automated runs, so that a developer who set an agent going is asked, every so often, whether they are still watching it.

That is what the new Ask response is for. When a Manifold policy is set to “Ask”, the agent's action stops. It waits for the developer to approve it. This works on every agent we support. Where the agent has a permission system of its own, we use it. Where it does not, the developer gets a consent dialog on their machine. Either way, nothing moves until someone answers.

Claude Code has an approval system. Cursor has one. Coverage used to stop there, which meant the security team had no way of knowing which developers a rule actually reached.

Every agent gets the policy

Every agent runs inside a harness, the coding tool the developer installed, and every harness falls into one of two groups.
Some harnesses ship with an approval system of their own, and they let Manifold speak through it. On those, the decision arrives as the harness's own permission prompt or inline message. It appears in the session the developer is already looking at. Claude Code, Cursor, Gemini CLI, GitHub Copilot and Antigravity work this way.
On the rest, Manifold raises the question itself, in a native OS dialog. Codex, Devin and Kimi work this way today.

Enforcement is the same in both columns. Only where the prompt appears changes.

Both columns exist because Manifold runs on the endpoint, next to the developer. An AI gateway or a proxy sits in the network path, where the only choices are letting the traffic through or blocking it. An EDR is on the machine, but it answers the same way, allow or block process execution. Neither can put the question to the developer who started the agent.

“Ask” stops the work and treats silence as a no

An “Ask” policy holds the action until the developer decides. That happens while the agent is mid-task. The tool call is evaluated, and it does not complete until somebody approves it.

The prompt names the rule that fired, the tool it stopped and the file it was about to touch. The developer approves or rejects. The agent carries on, or reports that it could not proceed.

Full auto mode does not get past it. A developer who has told their agent to stop asking has changed that agent's own settings, and a Manifold policy is not one of them. On the actions a policy covers, the question still arrives.

If the dialog cannot be shown, or the machine is locked, or the developer has gone to lunch, the action does not run. Silence is a rejection. An agent working through a task list at three in the morning is exactly the case that setting exists for.

Alert is how you find out what a rule catches

Alert lets the action through and tells someone it happened. The developer sees a message in their session or a notification on their desktop. The event is recorded centrally. Nothing is interrupted.

Alert is usually how a new rule gets adopted. A team writing a new rule rarely knows how often it will fire or who it will catch. Ship it as a block straight away and the first casualty is a developer doing something legitimate. The security team then spends a month defending the rule instead of tuning it.

Run the same rule as an Alert for two weeks. You get its real hit rate and the names of the people it touches. That tells you which of those actions should stop and ask a person, and which few should be denied outright. Some rules turn out to catch nothing worth catching, and those go.

What it looks like when an agent reaches for a credentials file

Back to the credentials read from the opening. A developer asks their agent to get a service running locally. The agent decides it needs to read .env. On most projects that file holds live credentials. This time the company has an “Ask” policy on credential files.

The read is evaluated before it completes. The developer sees a prompt naming the file and the rule. It appears in the agent on some tools and on the desktop on others. They approve and the agent continues. They reject, or never answer, and the read fails. The attempt is recorded either way, tied to the policy, the agent, the user and the machine it ran on.

Change the policy to Alert and the read goes through. The developer is told. The record is identical. The security team gets the same history either way. What changes is whether the developer is interrupted.

Tool choice moves faster than policy review

Developers switch agents faster than security teams can review them. The tool a developer installed this month should not decide which company rules reach them.
“Ask” is available to everyone now. There are no preset policies yet, so you build the rule yourself: a policy decides which actions raise the question, and you write the wording the developer sees.