Security breaks when responsibility is separated from runtime control. Developers may define an agent’s initial behaviour, but they do not continuously observe tool use, scope drift, or unsanctioned deployments. Without operational evidence and ownership, the programme becomes a paperwork model rather than a control model.
Why This Matters for Security Teams
Assigning AI security only to developers creates a gap between design-time intent and runtime control. Developers can define prompts, tool schemas, and initial guardrails, but they rarely own the live permissions, secret rotation, deployment approvals, or incident response needed once an agent is running. That split is especially dangerous when agents can call tools, chain actions, and keep operating after the original code review is already stale.
In practice, the failure is not just missed fixes. It is missed accountability. A developer-centric model often assumes security will be inherited through code quality, yet agentic systems change behavior through prompt updates, context drift, external APIs, and new integrations. Current guidance suggests this should be managed as an operational control problem, not a coding-only concern. NHI Management Group’s research on the LLMjacking threat shows why credential exposure becomes an immediate execution path for attackers, with hostile access attempts sometimes starting within minutes. The same pattern appears in the DeepSeek breach, where exposed secrets and records turned a software problem into an identity and access problem. In practice, many security teams encounter the gap only after an agent has already used a sensitive tool or leaked data, rather than through intentional governance.
How It Works in Practice
AI security responsibility has to follow the control plane, not stop at the development team. For autonomous or semi-autonomous systems, the relevant questions are: who approves tool access, who reviews live prompts and outputs, who watches for scope drift, and who can revoke credentials in real time. If those answers all point back to developers, then operational visibility is too thin to catch abuse, especially when agents use short-lived sessions and compound small permissions into larger actions.
Practically, the strongest model separates design responsibility from runtime ownership. Developers can document intended behavior, but security and platform teams should enforce policy at execution time using context-aware controls, workload identity, and just-in-time provisioning. That means the agent proves what it is through an identity primitive such as SPIFFE or OIDC, then receives only the secrets and API access needed for the current task. Policies should be evaluated at request time, not encoded once and assumed safe forever. This is consistent with the direction of CSA MAESTRO agentic AI threat modeling framework and the control logic explored in Anthropic Project Glasswing. It also aligns with NHIMG’s findings in the State of Secrets in AppSec, where secret fragmentation and delayed remediation show why static ownership breaks down.
- Use runtime authorization for every tool call, not just pre-deployment review.
- Issue ephemeral credentials per task and revoke them automatically when the task ends.
- Assign operational ownership for logs, alerts, and kill-switches outside the developer function.
- Track live agent behavior against approved intent, not only against source code.
These controls tend to break down in fast-moving environments where agents are deployed through CI/CD without a separate runtime approval gate, because the system rewards shipping code faster than verifying execution authority.
Common Variations and Edge Cases
Tighter runtime control often increases coordination overhead, requiring organisations to balance agility against assurance. That tradeoff is real, especially where developers also operate the platform or where a small team owns both application logic and incident response. In those environments, a split ownership model can feel redundant, but it is still better than leaving live agent behavior unmanaged.
There is no universal standard for this yet, but current guidance suggests that high-risk workloads should not rely on the same people who write the agent to also be the only people who govern its live permissions. For low-risk internal assistants, developers may retain more day-to-day responsibility if a separate security control plane still handles secrets, logging, and revocation. For external-facing agents, the operational model should be stricter because a prompt injection, misrouted tool call, or exposed credential can create rapid blast radius. This is where the difference between policy design and policy enforcement matters most. A developer can help define the rules, but security teams need authority to stop a tool call, rotate a token, or suspend an agent when behavior changes. The lesson from the Google Firebase misconfiguration breach is that configuration drift becomes an exposure path when no one is operationally accountable for it.
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 CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A03 | Developer-only ownership misses runtime agent abuse and unsafe tool use. |
| CSA MAESTRO | TRM | MAESTRO emphasizes threat modeling across agent runtime behaviors and tool chains. |
| NIST AI RMF | AI RMF governance addresses accountability gaps between builders and operators. |
Define accountable owners for monitoring, escalation, and mitigation throughout the AI lifecycle.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
