Accountability should sit across AppSec, platform engineering, IAM, and risk leadership, because the failure points span code, identity, and release operations. The right owner is the team that can enforce policy at runtime and prove it across the delivery chain. If ownership is fragmented, the control gaps will be too.
Why This Matters for Security Teams
Agentic development security is not just a software delivery concern. It determines whether an AI-enabled system can be trusted to plan actions, call tools, handle secrets, and move work through release pipelines without creating new attack paths. Accountability matters because control failures often appear first as identity misuse, unsafe tool access, or unreviewed model behaviour. Guidance from the NIST AI Risk Management Framework is useful here because it treats AI risk as a lifecycle issue, not a one-time approval.
Security teams often get this wrong by assigning ownership to whichever group adopted the tooling first. That leaves AppSec responsible for code, platform engineering responsible for deployment, and IAM responsible for credentials, while no one is clearly accountable for the combined attack surface created by agentic workflows. The better model is shared execution with a named risk owner who can force policy decisions across build, release, identity, and runtime control planes. For agentic systems, that includes the ability to answer who approved tool scopes, who can revoke them, and who verifies that changes remain within policy after deployment. In practice, many security teams encounter the accountability gap only after an agent has already been granted broad tool access rather than through intentional governance.
How It Works in Practice
Operational accountability should be split by control domain, but not diluted. AppSec usually owns secure design patterns, code review requirements, and testing gates. Platform engineering owns the runtime guardrails, deployment integrity, and enforcement points in CI/CD and production. IAM owns identity binding, workload authentication, credential lifecycle, and privileged access constraints. Risk leadership or a designated control owner owns exception approval, residual risk acceptance, and evidence that governance is functioning. This division aligns well with NIST Cybersecurity Framework 2.0 because governance, protection, and detection all need explicit ownership.
For agentic development, the practical question is not simply “who owns the AI?” but “who can stop unsafe action before it reaches users or production systems?” That requires control over:
- Approved model and package sources, including dependency provenance and version pinning.
- Tool permissions for agents, especially write actions, network calls, and secrets retrieval.
- Review of prompts, policies, and orchestration logic that can change behaviour without code changes.
- Telemetry for agent decisions, including traces that show what tool was called, with which identity, and why.
- Rollback and revocation paths when a model, prompt, or integration behaves unexpectedly.
This is where identity governance becomes central. If an agent can impersonate a service, use a secret, or chain calls across environments, then NHI governance is part of software governance. The OWASP Non-Human Identity Top 10 is relevant whenever machine identities, tokens, and service accounts are part of the delivery chain. The control owner should require a complete inventory of those identities, tie them to a business purpose, and enforce revocation when the purpose ends. These controls tend to break down in fast-moving platform teams where agents can create or reuse credentials outside the normal approval path because the runtime trust boundary is not formally documented.
Common Variations and Edge Cases
Tighter governance often increases delivery friction, so organisations must balance release speed against the cost of rework, exception handling, and evidence collection. Best practice is evolving for autonomous agents, and there is no universal standard for this yet. Some teams centralise accountability in a platform security function; others keep it in product teams with strong risk oversight. The right answer depends on whether the system can act independently, reach external services, or modify production state without human confirmation.
For higher-risk deployments, accountability should extend beyond internal teams to include supply chain governance over model providers, open-source components, orchestration libraries, and external APIs. The OWASP Top 10 for Agentic Applications 2026 and the MITRE ATLAS adversarial AI threat matrix are helpful for mapping abuse paths, while the CSA MAESTRO agentic AI threat modeling framework can support structured threat review. In practice, accountability gets blurred when vendors, internal platform teams, and product owners all assume someone else approved the integration, especially when a model update silently changes tool-use behaviour.
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, OWASP Non-Human Identity Top 10 and MITRE ATLAS address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | AI RMF frames lifecycle accountability for agentic systems and their risk decisions. | |
| OWASP Agentic AI Top 10 | Agentic app risks map to tool misuse, prompt issues, and unsafe autonomy. | |
| NIST CSF 2.0 | GV.RM | Governance and risk management require explicit ownership across delivery and runtime controls. |
| OWASP Non-Human Identity Top 10 | Non-human identities are central when agents use tokens, secrets, or service accounts. | |
| MITRE ATLAS | Adversarial AI tactics help identify misuse paths in agentic workflows and supply chains. |
Assign a named risk owner for the full AI lifecycle, including approvals, monitoring, and rollback.
