Autonomous software is a system that can choose actions and execute them without a human approving every step. The security challenge is not just access, but control over decision points, delegated permissions, and the evidence needed to explain those decisions after the fact.
Expanded Definition
Autonomous software sits between traditional automation and human-operated systems: it can interpret context, select a course of action, and use delegated tools or credentials to carry out that action. In NHI security, the key question is not simply whether the software has access, but whether its decision rights are bounded, observable, and revocable. Definitions vary across vendors, especially when teams label any workflow automation as “agentic” or “autonomous,” even when the system only follows fixed rules. The more precise view aligns with the risk framing in the OWASP Agentic AI Top 10 and the governance approach in the NIST AI Risk Management Framework: autonomy creates a control surface around prompt inputs, policy constraints, tool use, and post-action evidence.
That distinction matters because autonomous software may hold secrets, inherit service account privileges, or trigger changes in production without a human approving each step. NHI teams should treat it as an identity-bearing actor with bounded authority, not as a passive application component. The most common misapplication is calling deterministic automation “autonomous” when no decision point exists, which occurs when teams ignore whether the system can independently choose between multiple actions.
Examples and Use Cases
Implementing autonomous software rigorously often introduces a governance tradeoff: stronger guardrails reduce speed and flexibility, but they also reduce the blast radius when an agent acts incorrectly.
- An incident-response agent can isolate a workload, revoke tokens, and open a ticket, but only if its delegated permissions are scoped to those exact actions and time-bound through Ultimate Guide to NHIs — 2025 Outlook and Predictions guidance.
- A software engineering agent may create pull requests, run tests, and update dependency files, yet it should not have unrestricted write access to production secrets or deployment keys, as highlighted in Analysis of Claude Code Security.
- A customer support agent can retrieve account data and draft replies, but policy controls should prevent it from exposing information outside the current case context, a pattern often discussed in NIST AI Risk Management Framework workflows.
- An orchestration agent may call APIs across SaaS tools, but each connector should be treated like a privileged NHI and reviewed against the attack patterns in the OWASP NHI Top 10.
These use cases become safer when intent, tool scope, and logging are designed together instead of added later.
Why It Matters in NHI Security
Autonomous software matters because it can turn a credential into action faster than most teams can detect or interrupt. Once a system can choose between multiple actions, every embedded secret, service account, and API token becomes part of a live decision chain. NHIMG research shows that 80% of organisations report AI agents have already performed actions beyond their intended scope, and 52% can track and audit the data those agents access, leaving the rest with a compliance blind spot. That is a direct NHI governance problem, not just an AI operations issue. The same risk pattern appears in NHI misuse more broadly, where secrets sprawl and excessive privilege make unintended execution possible, as discussed in the Ultimate Guide to NHIs and the Moltbook AI agent keys breach.
Practitioners also need to recognise that autonomous software can collapse separation of duties if its identity is allowed to request, approve, and execute actions within the same session. That is why logging, consent boundaries, short-lived credentials, and rollback plans are core controls, not optional extras. Organisations typically encounter the operational cost of autonomous software only after an agent misroutes data, changes a system state, or exposes a secret, at which point the term becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Autonomous software often depends on secrets, tokens, and scoped tool access. |
| OWASP Agentic AI Top 10 | A1 | Agentic systems must be bounded where tool use and action selection create risk. |
| NIST AI RMF | Defines risk governance for AI systems that can operate with limited human oversight. | |
| NIST CSF 2.0 | PR.AC | Least-privilege access and identity control apply directly to autonomous execution. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification of every action source, including autonomous software. |
Document autonomy limits, monitor outcomes, and maintain human accountability for decisions.
Related resources from NHI Mgmt Group
- How should security teams govern autonomous coding agents in software delivery pipelines?
- Why do autonomous AI agents complicate incident response and accountability in software supply chain attacks?
- What NHI security controls are mandatory for autonomous Agentic AI?
- Why do autonomous agents create more lateral movement risk?
