Who should be accountable for access decisions when autonomous agents are changing infrastructure?

Why This Matters for Security Teams

When autonomous agents can change infrastructure, accountability is not a paperwork exercise. It determines who can approve risky actions, who can stop them, and who has to answer when an agent creates drift, exposure, or outage. The practical problem is that agentic systems do not behave like a human operator with a stable job role. They chain tools, act at machine speed, and may execute outside the expectations of the team that deployed them. NHIMG’s 2026 Infrastructure Identity Survey reports that 52% of respondents already see AI security decision-making power shifting toward platform and infrastructure teams.

That shift is healthy only if it comes with explicit ownership, not implicit blame. Security teams should treat agent access decisions like production change authority: scoped, reviewable, revocable, and tied to the systems actually at risk. Guidance from the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 both point toward governed runtime decisions, not trust-by-role. In practice, many security teams encounter the accountability gap only after an agent has already altered infrastructure or exposed secrets.

How It Works in Practice

The right accountability model starts with named custodians for each layer the agent can touch: application owners, platform engineers, infrastructure operators, identity administrators, and security governance. Platform and infrastructure teams should own the system permissions because they control the blast radius. Security should define policy, exception handling, and revocation thresholds. Identity teams should enforce how the agent authenticates, what credentials it receives, and when those credentials expire.

For autonomous agents, static RBAC is not enough. A role can describe a job family, but it cannot predict the exact sequence of actions an agent will attempt. Better practice is emerging around intent-based authorization and policy-as-code, where a runtime engine evaluates the agent’s request in context: what it is trying to do, which environment it is in, whether the target is production, and whether the action exceeds expected scope. That approach is consistent with CSA MAESTRO agentic AI threat modeling framework and the NIST AI Risk Management Framework.

Operationally, accountability becomes enforceable when agents receive just-in-time, ephemeral credentials tied to a specific task, rather than broad standing access. Workload identity is the anchor here: the system should know what the agent is through cryptographic identity, not only what password or token it happens to hold. Standards and ecosystem patterns such as OWASP Non-Human Identity Top 10 and infrastructure controls aligned to NIST SP 800-53 Rev. 5 Security and Privacy Controls support that model.

NHIMG’s research on Replit AI Tool Database Deletion shows why this matters: if an agent can make destructive changes, the organisation needs a revocation path that works before the next command executes. These controls tend to break down in loosely governed multi-cloud environments where teams share ownership informally and no single group can revoke agent privileges quickly.

Common Variations and Edge Cases

Tighter accountability often increases change-control overhead, so organisations have to balance speed against the cost of review and rollback. That tradeoff becomes sharper when agents are used in ephemeral environments, CI/CD pipelines, or self-healing infrastructure, where the right answer may be “approve by policy” rather than “approve every action.”

There is no universal standard for this yet, but current guidance suggests the most reliable model is shared accountability with clear primaries: platform owns execution, infrastructure owns resource impact, identity owns credential issuance, and security owns the policy boundary. Executive ownership still matters for risk acceptance, but executives should not be the operational approvers for every agent decision. The real control is the ability to say no in real time.

Edge cases appear when agents operate across tenant boundaries, call external APIs, or delegate work to other agents. In those cases, accountability must extend to downstream tool permissions and vendor integrations, not just the original agent process. NHIMG’s reporting on CoPhish OAuth Token Theft via Copilot Studio and the broader OWASP Agentic Applications Top 10 underline the same lesson: if a delegated tool path can be abused, accountability must include whoever approves that path and whoever can revoke it.

Where organisations fail is not usually the policy statement. It is the absence of an on-call human who can remove authority when an agent starts acting outside its intent.

Related resources from NHI Mgmt Group

• Who is accountable when an autonomous corporate actor changes infrastructure or access?
• Who is accountable when an autonomous system acts on access decisions?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?