Who should be accountable for securing autonomous systems across security and platform teams?

Accountability should sit with the teams that design, approve, and operate the agent’s access path, not with a single security function alone. Platform, identity, application, and security teams each own part of the control chain. Clear ownership is needed for credential issuance, policy enforcement, monitoring, and incident response when an agent behaves unexpectedly.

Why This Matters for Security Teams

Autonomous systems blur the old boundary between platform operations and security ownership. An agent can request tools, chain actions, and continue execution without a human in the loop, so accountability cannot stop at “who deployed it.” Current guidance suggests that the teams approving identity, policy, runtime access, and logging each own part of the control chain, especially when agent behaviour is dynamic and goal-driven. That is why NHI governance and agentic AI security must be treated as an operating model issue, not a ticket queue.

The practical risk is simple: if no one owns the access path end to end, over-privilege, stale secrets, and missing audit trails become normal. The NHI attack patterns NHIMG tracks in The State of Non-Human Identity Security show how often failure begins with controls that looked acceptable on paper but did not hold up in production. For agentic workloads, that gap widens because behaviour changes at runtime. The same issue appears in the AI Agents: The New Attack Surface report, where organisations report agents acting beyond intended scope. In practice, many security teams encounter accountability breakdowns only after an agent has already accessed something it was never meant to touch.

How It Works in Practice

Accountability should be split by control plane, then tied back together with explicit ownership and escalation paths. Platform teams usually own the runtime, orchestration layer, and service integration points. Identity teams own workload identity, token issuance, and secret lifecycle. Security teams own policy design, monitoring, and response criteria. Application owners own the agent’s purpose, allowed tools, and business impact. That division works only if each team is accountable for a concrete control outcome, not a vague shared responsibility statement.

For autonomous systems, static RBAC is usually too blunt because agents do not follow fixed human job patterns. Best practice is evolving toward intent-based authorization, where policy decisions are evaluated at request time using context such as task, data sensitivity, environment, and current risk. That is consistent with the NIST AI Risk Management Framework and the CSA MAESTRO agentic AI threat modeling framework, both of which emphasise governance, traceability, and risk-informed controls.

• Use workload identity for the agent, not shared human credentials, so the system can prove what it is.
• Issue JIT, short-lived secrets per task and revoke them automatically on completion.
• Evaluate policy at runtime with policy-as-code rather than granting broad pre-approved access.
• Log every tool call, token exchange, and data access path for audit and incident response.

NHIMG’s OWASP Agentic Applications Top 10 reinforces that tool abuse, prompt injection, and privilege escalation are control problems, not just model problems. These controls tend to break down in legacy environments where agents inherit long-lived service accounts and where runtime policy enforcement is not available at the tool boundary.

Common Variations and Edge Cases

Tighter accountability often increases coordination overhead, requiring organisations to balance faster delivery against stronger control coverage. That tradeoff becomes visible when teams run multiple agents across different business functions, each with its own data access and execution path. There is no universal standard for this yet, but current guidance suggests that one named control owner should exist for every critical agent, even if several teams contribute to the implementation.

Edge cases usually appear where security and platform ownership overlap. For example, if a platform team manages the orchestration service but security sets the policy engine, both can assume the other owns enforcement gaps. The same ambiguity appears when vendors manage the agent framework while internal teams manage the secrets store. In those cases, accountability should follow the control that can actually stop harmful behaviour, not the team that merely observes it. The NHIMG research on OWASP Agentic Applications Top 10 and Ultimate Guide to NHIs both point to the same lesson: ownership fails when no team can prove it controls the runtime identity and revocation path.

Organisations should be especially careful in multi-agent pipelines, where one agent can inherit outputs from another and amplify a small policy gap into a larger incident. These scenarios are still evolving, so the best practice is to define accountable owners for each stage of identity issuance, approval, monitoring, and emergency shutdown before the first production deployment.

Related resources from NHI Mgmt Group

• Who should be accountable for securing disconnected applications across business and security teams?
• How should security teams reduce identity risk when access is spread across multiple systems and policies are applied inconsistently?
• Who should be accountable for AI agent access and fraud controls across security, identity, and business teams?
• How should security teams match identities across source control, ticketing, and identity systems?