Defined Authority

Expanded Definition

Defined authority is the operational contract for an AI agent or other NHI. It sets the approved scope, ties the identity to an owner, and makes the boundary testable through review, logging, and policy enforcement. In practice, it sits between design intent and runtime control.

Definitions vary across vendors when the term is used loosely to mean access policy, delegation, or workflow approval. In NHI governance, that is too narrow. Defined authority should capture purpose, tool access, data access, escalation limits, and the review cadence that keeps the approval current. This maps cleanly to NIST Cybersecurity Framework 2.0 because the framework expects governance, access control, and ongoing oversight to be connected rather than treated as separate tasks.

The boundary matters most when an AI Agent can act autonomously across systems. Without a written authority statement, teams often confuse what the agent is technically able to do with what it is authorised to do. The most common misapplication is treating inherited platform permissions as defined authority, which occurs when runtime access is granted before purpose, owner, and limits are documented.

Examples and Use Cases

Implementing defined authority rigorously often introduces slower onboarding and more review overhead, requiring organisations to weigh deployment speed against control, accountability, and blast-radius reduction.

• An agent that opens tickets in a service desk may have authority to create and update records, but not to close incidents without human approval.
• A retrieval assistant may be allowed to read approved knowledge sources, yet denied access to production secrets, customer exports, or admin consoles.
• A deployment agent may run approved scripts in a limited environment, with its authority narrowed to JIT access during maintenance windows and revoked afterward.
• A finance workflow agent may trigger reminders and reconcile status, but remain blocked from initiating payments unless a separate control path is approved.
• Security teams can compare the documented authority statement against the actual grants observed in logs, a practice aligned with guidance in the Ultimate Guide to NHIs and the least-privilege approach reinforced by NIST Cybersecurity Framework 2.0.

In mature programs, the document is not static. It is updated when the agent gains a new tool, changes business purpose, or is repurposed for a different dataset. That is where defined authority becomes a governance artifact instead of a one-time approval.

Why It Matters in NHI Security

Defined authority is one of the few controls that turns agentic behaviour into something auditable. When it is missing, organisations tend to grant broad permissions first and ask questions later, which is exactly how overprivileged NHIs become difficult to contain. NHIMG research shows that Ultimate Guide to NHIs reports 97% of NHIs carry excessive privileges, a sign that documented scope and actual access often diverge.

That divergence creates governance failures across lifecycle management, incident response, and third-party oversight. It also weakens Zero Trust Architecture because policy enforcement depends on knowing what each identity is supposed to do, not just what it can technically reach. The same logic appears in NIST Cybersecurity Framework 2.0, where access control and continuous monitoring only work when the asset or identity has a clear, current role.

Organisations typically encounter the consequences only after a misuse, outage, or leaked credential reveals that the agent had far more authority than anyone intended, at which point defined authority becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What is the difference between identity governance and authority governance?
• Delegated Agent Authority
• Authority Governance