Ask policies bring consistent approval control to every coding agent

At a glance

What this is: Manifold Security describes a policy model that extends Ask, Alert and Deny responses across every supported coding agent, with Ask pausing execution until a developer responds.

Why it matters: This matters because developers and their agents share high-trust access, so policy has to shape action at runtime instead of relying on after-the-fact logging alone.

Context

The governance gap here is not whether a rule exists, but whether it can actually intervene at the point of action across the full developer-agent stack. If a policy only reaches some harnesses, security teams get inconsistent enforcement and developers learn to work around controls that vary by tool.

In practice, the problem is a split between observability and intervention. Alert tells you what happened, while Ask pauses the action before completion, which is a different control objective for developer-run automation and one that better fits workflows where the same agent may touch credentials, code, or deployment paths.

Key questions

Q: How should security teams roll out policy controls for coding agents without blocking legitimate work?

A: Start with Alert so you can measure what the rule actually catches, then promote only the actions that clearly need human approval or outright denial. That sequencing gives you real hit rates, identifies who is affected, and reduces the chance that teams abandon the policy because it interrupts normal development work too often.

Q: What breaks when a policy only logs agent activity instead of pausing the action?

A: Logging alone cannot stop a sensitive action from completing, so the control arrives after the risk has already materialised. If the agent can read a credentials file, invoke a destructive command, or continue a long run without interruption, then the governance decision has become forensic rather than preventative.

Q: Why do developer agents need approval at the action level instead of the session level?

A: Because a session can contain both harmless and risky steps, and the risky one may appear halfway through a routine task. Action-level approval lets teams question a single read or write without forcing the entire workflow to stop, which is the practical difference between usable governance and blanket restriction.

Q: What should teams do when the same agent framework exposes different approval surfaces?

A: Set the policy once and enforce it where the action is executed, not where the prompt happens to appear. Whether the approval shows up inside the harness or as a local consent dialog, the control should behave the same so developers experience one consistent rule set.

Technical breakdown

How Ask, Alert and Deny differ in agent policy enforcement

Ask, Alert and Deny are not just three labels. They represent three different intervention points in an agent workflow. Ask pauses the tool call and waits for an explicit human response before the action completes. Alert allows the action to finish and records it for later review. Deny blocks the action outright. That distinction matters because the same policy outcome can be delivered through different surfaces, such as an agent’s native approval prompt or an operating-system dialog, while still enforcing the same decision. The architectural point is that enforcement is tied to the endpoint and the execution moment, not to a network proxy that only sees traffic.

Practical implication: Treat Ask as a runtime control for high-uncertainty actions, and use Alert to measure policy fit before you hard-block anything.

Why endpoint enforcement matters more than network-path controls

An AI gateway or proxy can only allow or block traffic in the network path. That is too coarse for a developer-controlled agent that needs a decision mid-task, because the security team may want to stop one file read, question one upload, or let the rest of the workflow continue. Endpoint enforcement sits beside the developer and can surface the prompt inside the same session the developer is already using, or on the local machine if the harness lacks a native approval system. That makes the control operationally different from centralised traffic inspection. It also explains why the policy can remain consistent even when the prompt surface changes across tools.

Practical implication: Place policy enforcement where the action is initiated if you need per-action decisions instead of broad network allow or deny choices.

Why credentials and other sensitive file reads need action-level governance

The article’s credentials example shows the real risk pattern. An agent can decide it needs to read a file like .env while carrying out a legitimate task, and that read may happen before a human notices anything unusual. In that moment, the policy question is not whether the agent is allowed to run in general. It is whether this specific read should proceed, be logged, or require human confirmation. That is a classic action-scoped governance problem: the same agent may be safe for one file and unsafe for another, even within the same session. Static permission models are too blunt for that distinction. See the AI Agent Memory Security Guide.

Practical implication: Classify sensitive reads and similar high-risk actions separately from general agent access, then decide which ones must pause for review.

NHI Mgmt Group analysis

Runtime policy has become the real control plane for developer agents. When an agent runs with the developer’s own access, the important question is no longer whether the tool is allowed onto the endpoint. It is whether the organisation can shape individual actions as they happen, across every harness that developer might use. That changes governance from inventorying tools to governing decisions at runtime. The practical conclusion is that policy architecture now needs per-action enforcement, not just platform approval.

Alert-only governance is useful for discovery but insufficient for high-risk actions. The article’s sequencing is sound: first observe what a rule would catch, then decide whether it should ask or deny. That pattern reduces the chance of overblocking legitimate work. It also creates a cleaner governance model for developer productivity, because the team learns where the real friction is before it turns enforcement on. The practitioner takeaway is to treat Alert as a calibration stage, not as the end state.

Developer trust is now part of the control design, not an afterthought. Security teams can no longer assume that the strongest policy is the most acceptable one. When the blocked user is a developer, the governance question includes workflow disruption, not only security posture. That is why an Ask response can be more durable than a blanket block, especially for unusual but legitimate actions. The implication is that usable governance beats theoretical strictness when the same person is both the operator and the target of the control.

Action-scoped governance is the right model for agentic work, not session-scoped assumptions. A policy that lets a session begin safely can still fail on a single credential read, a destructive file operation, or an unsupervised long-running task. That is the core lesson from the article’s control model. The field should stop treating a whole agent session as one trust decision and start treating each meaningful action as its own governance event. Practitioners should design for per-action accountability, not session-level faith.

From our research library:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Action-scoped governance is becoming the baseline for agent controls. Session-level trust is too coarse when a coding agent can touch secrets, source code and deployment-adjacent files in the same run. Programmes that still rely on log-only oversight will need to move the decision closer to the action itself, especially as developers adopt more than one harness across the estate.

As agent usage expands, the practical boundary will be whether the control can interrupt a tool call without turning every unusual event into a hard block. That pushes identity and security teams toward policies that distinguish between observation, human review and denial, instead of assuming one enforcement mode fits every risk.

For practitioners

• Define three policy outcomes by action type Use Ask for actions that need human judgement, Alert for actions you want to observe first, and Deny only for a short list of clearly unsafe actions.
• Run new policies in Alert before enforcement Use a monitoring period to measure real hit rates, identify which developers are touched, and separate legitimate friction from unacceptable behaviour.
• Classify sensitive file reads as review-worthy actions Treat reads of credential files, tokens, and similar secrets as distinct governance events rather than as ordinary file access inside the agent session.
• Align enforcement with the execution surface Make sure the policy can pause the action whether the prompt appears in the harness or in a local consent dialog on the machine.

Key takeaways

• The article shows that agent governance is shifting from post-event visibility to per-action intervention at the point of execution.
• Ask, Alert and Deny serve different purposes, and the most durable policy design starts by observing before it enforces.
• Sensitive reads such as credentials files need their own policy treatment because a routine task can still expose high-value access.

Related NHI Mgmt Group resources: AI Agent Memory Security Guide · AI Agent Observability, Audit and Incident Response Guide · Browser and Computer-Use Agent Security Guide

Key terms

• Ask policy: An Ask policy pauses an action and requires a human decision before the action can complete. In agentic workflows, it is a runtime control that turns a tool call into a review point rather than a silent execution step.
• Alert policy: An Alert policy allows the action to proceed while recording the event for later review. It is useful for measuring policy fit and discovering where a proposed control would interrupt legitimate work before enforcement is tightened.
• Deny Policy Coverage: Deny policy coverage is the portion of a cloud provider's permission set that can be centrally blocked using explicit denial rules. If coverage is incomplete, some permissions can still be granted but cannot be denied through the same control path, leaving gaps in least-privilege enforcement.
• Session-scoped governance: Session-scoped governance means security decisions are enforced within the live user session rather than only at login or on the network edge. It allows controls to respond to identity, device posture, and action context as work unfolds, which is especially useful in hybrid environments with unmanaged devices and sensitive workflows.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.