How do organisations decide which controls matter most for agentic development?

Why This Matters for Security Teams

Agentic development changes the control question from “Is the model accurate?” to “What can this system do, on whose authority, and with what evidence?” That shift matters because an agent with tool access can create tickets, query data, modify records, or trigger workflows, which turns weak governance into a live security issue. The right controls are the ones that reduce blast radius before deployment, not the ones that only improve review quality after the fact. Guidance from the NIST AI Risk Management Framework is useful here because it pushes teams to map risk, measure impact, and assign accountability rather than treating every AI use case the same.

Practitioners often overfocus on content moderation or output scoring and underfocus on execution authority, data boundaries, and change control. That creates a false sense of safety when the actual risk sits in the agent’s ability to act across systems, chain tools, or reuse credentials. In practice, many security teams encounter agentic misuse only after a workflow has already touched production, rather than through intentional control design.

How It Works in Practice

Effective control selection starts by classifying the agent’s operating model. A read-only assistant used for summarisation has different priorities from an autonomous workflow that can approve payments, rotate secrets, or deploy code. Security teams should rank controls by the harm that could follow a compromise, a bad instruction, or a poisoned toolchain, then place the strongest barriers around the most consequential actions.

At minimum, the control stack usually includes boundary restrictions, execution logging, approval gates for sensitive actions, and validation of inputs and outputs. The OWASP Agentic AI Top 10 is helpful because it highlights risks such as tool misuse, prompt injection, and excessive agency. For threat modelling, many teams also map likely attack paths against the MITRE ATLAS adversarial AI threat matrix so detection and response are aligned to realistic abuse patterns.

• Limit tool scope to the smallest set of actions the agent actually needs.
• Require logged execution identity so every action is attributable to a specific agent instance.
• Use policy enforcement points for data access, network calls, and downstream writes.
• Separate human approval from routine operation, then reserve approval for high-impact decisions only.
• Validate outputs against business rules, not just language quality or formatting.

For systems that interact with software delivery or cloud operations, control priority should also reflect supply chain risk. The most useful question is whether the agent can introduce change into a trusted workflow without strong review. These controls tend to break down when the agent is embedded in legacy automation that already has broad service account privileges because the inherited trust becomes the easiest path to misuse.

Common Variations and Edge Cases

Tighter controls often increase friction, latency, and build complexity, so organisations have to balance speed against containment. That tradeoff is real in agentic development, especially when product teams want autonomous behaviour but security teams need proof that actions are bounded and reversible. Best practice is evolving, and there is no universal standard for how much autonomy is acceptable in every environment.

One common edge case is an agent that cannot write to production directly but can still shape decisions by creating pull requests, altering configuration suggestions, or enriching tickets. Those indirect paths still matter because control failure can happen through workflow influence rather than direct access. Another edge case is multi-agent orchestration, where one agent delegates to another and the accountability chain becomes unclear. In those situations, CSA MAESTRO agentic AI threat modeling framework can help teams reason about trust boundaries between agents, tools, and human operators.

When organisations operate in regulated or high-assurance environments, the control set should be more conservative: stronger approval gates, tighter data segmentation, and more aggressive monitoring for anomalous tool use. For emerging agentic deployments, the practical rule is simple: controls should follow action risk, not model novelty. The most useful controls are the ones that make unsafe actions difficult even when the agent is fooled, overprivileged, or misrouted by design.

Related resources from NHI Mgmt Group

• How can organisations decide which AI agent controls matter most?
• How should organisations decide whether existing identity controls are enough for agentic AI?
• How do organisations decide where AI data security controls should sit?
• What should organisations review before adopting agentic API access controls?