How do security teams balance developer velocity with control over AI agent actions?

Why This Matters for Security Teams

Security teams are being asked to preserve developer velocity while preventing AI agents from turning fast execution into uncontrolled action. That is a different problem from traditional appsec, because agents can chain tools, adapt their behaviour at runtime, and take actions that were never explicitly coded as a workflow. Current guidance from OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point to runtime governance, not static approval gates, as the practical control plane.

That matters because velocity is usually lost when controls are bolted on as separate steps, tickets, or manual reviews. Developers bypass those paths, or they route around them by hardcoding exceptions. NHI Management Group research in AI Agents: The New Attack Surface found that 80% of organisations report AI agents have already acted beyond intended scope, yet only 44% have implemented policies to govern them. The lesson is simple: if the control is slower than the agent, it will be skipped. In practice, many security teams first notice this gap after an agent has already accessed a system it was not meant to touch.

How It Works in Practice

The workable pattern is to embed guardrails inside the execution path so the developer experience stays intact. Instead of asking teams to pre-approve every action, policy is evaluated at runtime against the agent’s intent, the resource being requested, the user or system context, and the risk of the specific operation. That aligns with the direction of the CSA MAESTRO agentic AI threat modeling framework and the control expectations in OWASP Top 10 for Agentic Applications 2026.

• Use just-in-time permissions so the agent receives only the access needed for one task, then loses it automatically.
• Prefer workload identity over shared credentials, so the platform can prove what the agent is and what service instance is acting.
• Issue short-lived secrets and tokens with tight TTLs, especially for tool use, data retrieval, and write actions.
• Apply policy-as-code at request time, so blocked actions fail closed without changing the surrounding application logic.
• Log prompts, tool calls, policy decisions, and outputs together so developers can debug without weakening controls.

This approach preserves velocity because the developer still ships one workflow, but the platform controls what the agent can do at each step. NHI Management Group’s OWASP NHI Top 10 coverage and the AI Agents: The New Attack Surface report both show why this matters: once agents can invoke tools autonomously, static RBAC alone cannot describe the real action path. These controls tend to break down when an agent is allowed to compose multiple tools across systems because the effective privilege becomes emergent, not pre-defined.

Common Variations and Edge Cases

Tighter runtime control often increases operational overhead, so organisations have to balance low-friction delivery against the need for rapid containment. There is no universal standard for how much agent autonomy should be pre-approved versus evaluated per request, and current guidance suggests that the answer should change by data sensitivity, blast radius, and task repeatability.

For low-risk internal assistants, teams may allow broader read access with logging and post-action review. For code-writing or ticket-closing agents, best practice is evolving toward stricter write controls, scoped tokens, and stronger human confirmation before destructive steps. The biggest exceptions are environments with legacy shared accounts, long-lived API keys, or fragmented secrets management, because those patterns erase the distinction between one agent session and the next. That is exactly where control erodes fastest, and where a shared secret can turn a convenience feature into enterprise-wide privilege.

Two NHIMG findings are especially relevant here: the State of Secrets in AppSec report shows only 44% of developers consistently follow secrets best practices, while the agent research shows scope creep is already common. In other words, the velocity problem is usually not solved by asking developers to be more careful. It is solved by making the safe path the easiest path.

Related resources from NHI Mgmt Group

• How should security teams balance agility with identity control in cloud and AI environments?
• How should security teams implement AI agent email access without over-granting permissions?
• How should security teams handle approval for sensitive AI agent actions that happen asynchronously?
• What do security teams get wrong about AI agent scope control?