Security leaders should redesign operating models around shared workflows, not isolated handoffs. The article points to three priorities: rethink team structure, bridge the developer-security divide, and move from point-in-time assessments to continuous intelligence. That means embedding security guidance earlier, clarifying task ownership, and using always-on review so humans and machines collaborate around real risk, not just speed.
Why agentic AI changes the security-development operating model
agentic ai changes the question from “How do security and development exchange approvals?” to “How do they supervise shared execution safely?” When agents can draft code, open pull requests, query tools, and move work between systems, the old handoff model becomes too slow and too brittle. Security leaders need to treat this as an operating-model shift, not just a tooling upgrade. The practical issue is that speed without shared control often creates blind spots in OWASP Agentic AI Top 10 terms, where unsafe tool use and weak oversight can matter as much as model quality. In practice, many teams discover this only after agents have already been placed into delivery workflows without clear ownership, review thresholds, or escalation paths.
How security and development teams should work together in practice
The most effective response is to redesign collaboration around shared workflows, not separate queues. Security still defines guardrails, but those guardrails need to live inside the delivery path so developers can act on them while the work is being created, tested, and revised. That means security teams should focus less on static sign-off and more on continuous verification, policy-as-code where possible, and review points that trigger on meaningful risk rather than on arbitrary calendar gates.
Agentic AI makes this more important because decisions can now be generated and executed at machine speed. If a developer uses an agent to produce code, test changes, or propose infrastructure updates, security has to be able to inspect the intent, scope, and downstream effect of those actions. A useful operating model distinguishes three layers: what the agent is allowed to do, what humans must approve, and what telemetry is needed to detect drift. That is where guidance from NIST AI Risk Management Framework becomes especially relevant, because it frames AI oversight as a lifecycle discipline rather than a one-time review.
- Set explicit ownership for agent outputs that affect code, access, or production changes.
- Build shared review checkpoints for risky actions instead of routing everything through security after the fact.
- Use continuous monitoring to compare approved behaviour with actual agent activity.
- Keep humans accountable for exceptions, model changes, and workflow expansion.
Where teams get this right, security becomes a design constraint that developers can work with early, not a late-stage blocker that must catch up afterward. Where it breaks down is when organisations let agents operate across tools faster than they can define approval boundaries, evidence requirements, and rollback responsibility.
Where the handoff model breaks down as agents enter delivery workflows
Any move to tighter supervision creates overhead, so organisations have to balance faster delivery against more deliberate control. That trade-off becomes visible when teams want the benefits of agentic automation but still expect traditional approval chains to cover new kinds of work. The simple version of the old model, where development “owns build” and security “owns review,” no longer matches reality once an agent can participate in both phases.
There is still no universal consensus on how far to centralise agent governance. Some organisations keep security policy tightly centralised to reduce drift, while others distribute review rules into platform engineering and product teams to preserve delivery speed. The right choice depends on how much the agent can change, what systems it can reach, and how much consequence follows from a bad action. For high-risk workflows, alignment with the OWASP Top 10 for Agentic Applications 2026 helps teams recognise where tool misuse, unsafe autonomy, or weak oversight shifts the risk profile. The main edge case is partial autonomy: even limited agent permissions can be enough to create material exposure if the surrounding workflow assumes a human will notice every issue in time.
Teams also need to account for evidence quality. If the only record is a final output, leaders cannot tell whether a change came from a human decision, an agent suggestion, or a blended review path. That makes post-incident analysis harder and weakens accountability when something goes wrong. The governance model should therefore treat traceability as a working requirement, not an audit afterthought.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack surface, NIST AI RMF and CIS Controls v8 set the technical controls, and ISO/IEC 42001:2023 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A3 — Unsafe Tool Use and Actions | Agentic workflows can invoke tools and modify delivery systems. |
| Recommendation — Restrict agent tool access and require approval for actions that can change code, access, or production. | ||
| NIST AI RMF | GV — Govern | The question is about governing how AI changes team operating models. |
| Recommendation — Assign AI accountability, oversight, and escalation paths before agents enter shared workflows. | ||
| ISO/IEC 42001:2023 | 5 — Leadership and Commitment | Security leaders need an organisational AI governance operating model. |
| Recommendation — Embed AI governance into leadership ownership, roles, and review expectations across delivery teams. | ||
| CIS Controls v8 | 5 — Account Management | Agentic work changes access, approvals, and traceability around delivery actions. |
| Recommendation — Control access paths and review exception handling for accounts or automations that can affect delivery. | ||
| MITRE ATT&CK | T1218 — System Binary Proxy Execution | Agentic workflows may execute tools or proxy actions through trusted utilities. |
| Recommendation — Map agent-executed actions to abuse patterns and monitor for tool-mediated execution chains. | ||
Practitioner Guidance
What to prioritise: Define which agent actions are advisory, which are executable, and which require human approval before any broader rollout. The first control question is not whether the agent is useful, but whether the team can still explain who authorised a risky action and why.
What to verify: Check whether your current workflow records enough context to reconstruct decisions later, including the agent prompt or task, the affected system, the reviewer, and the exception path. If that evidence is missing, the operating model is not ready for scaled use.
Practitioner takeaway: Security leaders should govern agentic AI as shared execution with traceable accountability, because the main failure is not automation itself but automation outrunning the organisation’s ability to approve, observe, and reverse it.
Related resources from NHI Mgmt Group
- Why do AI agents force safety and security teams to work together?
- How do IAM and email security teams work together on AI-driven threats?
- How should security teams contain agentic AI attacks once execution starts?
- How should security teams implement AI-assisted development without losing visibility into what agents are changing in codebases?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
