What breaks when organisations treat agentic risk as only a security-team responsibility?

Why This Matters for Security Teams

When agentic risk is treated as a security-only problem, the organisation usually confuses control design with operational ownership. Security can define guardrails, but it rarely owns prompt design, tool integration, data classification, legal approvals, vendor risk, or the business outcome the agent is meant to achieve. That gap matters because autonomous agents do not behave like fixed apps: they chain tools, change actions by context, and expose new paths to secrets and data movement.

Current guidance in the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point toward shared accountability, because risk emerges across the full lifecycle, not just in the security queue. NHIMG research on The State of Non-Human Identity Security shows that only 1.5 out of 10 organisations are highly confident in securing NHIs, which is a strong signal that fragmented ownership is already failing in practice.

In practice, many security teams encounter agent abuse only after product, engineering, or operations has already connected the agent to sensitive systems without a clear owner for approval, logging, and revocation.

How It Works in Practice

Agentic governance fails when accountability stops at the security boundary. A useful operating model maps the agent’s lifecycle to named owners: product defines the use case and acceptable action scope, engineering implements tool constraints and telemetry, legal reviews data and retention exposure, and security sets policy, detection, and response expectations. That is the practical translation of shared responsibility in agentic systems, and it aligns with the intent of CSA MAESTRO agentic AI threat modeling framework.

For autonomous workloads, the key control plane is not a static access review. It is runtime authorization, short-lived credentials, and workload identity. Instead of giving an agent broad standing access, teams should issue task-scoped tokens, revoke them on completion, and bind tool use to cryptographic workload identity such as SPIFFE, OIDC, or similar attestation patterns. That approach is much closer to the realities described in OWASP NHI Top 10 and in implementation guidance from NIST Cybersecurity Framework 2.0.

• Define who approves agent actions, not just who approves the system.
• Attach each tool, dataset, and secret to a named business owner and a technical owner.
• Use policy-as-code for runtime decisions, not only quarterly access reviews.
• Log every high-risk action with agent identity, intent, target system, and policy decision.
• Revoke access automatically when the task ends or the context changes.

This guidance tends to break down in highly distributed environments where agents are embedded in many product teams and no single group owns the full action chain, because review, monitoring, and incident response then fragment across multiple handoffs.

Common Variations and Edge Cases

Tighter control often increases delivery friction, so organisations have to balance speed against the risk of unowned agent behaviour. The right balance depends on whether the agent can read, write, delete, or externally transmit data, and whether it operates on behalf of a human, a team, or itself. There is no universal standard for this yet, but current guidance suggests the higher the agent’s privilege and autonomy, the less acceptable it is to rely on a security-only model.

One common edge case is a pilot that starts as a narrow assistant and later gains tool access, cross-system permissions, and background execution. That is where security-only governance breaks: the control owner is still thinking about the original use case while the engineering team has already expanded the blast radius. Another is third-party agents or SaaS copilots, where contract terms, data handling, and integration approval sit outside security. NHIMG’s CoPhish OAuth Token Theft via Copilot Studio and Analysis of Claude Code Security both reflect how quickly agentic exposure crosses team boundaries.

Security teams should treat these cases as governance design problems, not just detection problems, and pair their controls with business ownership, legal review, and operational runbooks. That is the only way to avoid delayed containment when an agent’s actions exceed the assumptions made at approval time.

Related resources from NHI Mgmt Group

• What breaks when organisations treat employee security risk as a one-time onboarding issue?
• What breaks when organisations treat non-human identity risk as a secondary security issue?
• What breaks when security teams treat untrusted input and sensitive data as separate risk categories in agentic systems?
• When does just-in-time access reduce risk for agentic AI, and when does it fall short?