Before an agent gets authority
Authority is a property of the deployed system, not the prompt.
An agent becomes operationally consequential when it can use a tool, reach a system, disclose information, change state, or initiate a process. At that boundary, model behavior is only one part of the control problem. Identity, permissions, workflow rules, data provenance, human approval, monitoring, and recovery determine what the system can actually do.
NIST's 2025 lessons on tool use in agent systems frame tool analysis across functionality, access patterns, risk, reliability, modality, monitoring, and autonomy. The publication also distinguishes read-only access from constrained and broader write access, and notes that deployment-specific knowledge matters to risk assessment. See NIST's official tool-use taxonomy discussion.
Intelligence may propose an action. The enterprise system decides whether that action is permitted, observable, reversible, and owned.
Define the perimeter before granting the permission.
An authority envelope is the complete operating boundary around an agent. It is written in terms that business, engineering, security, legal, and operations leaders can inspect together. A permission without that shared context is too narrow a description of the risk.
- Purpose
- The named workflow result the agent is authorized to support; adjacent uses remain separate decisions.
- Principal
- The human or service identity on whose behalf the agent operates, including how identity is established and revoked.
- Systems and tools
- The specific applications, APIs, records, and interfaces the agent may reach, with read and write permissions separated.
- Data classes
- The information the workflow may retrieve, transform, generate, retain, or disclose—and the provenance required for each class.
- Decision boundary
- The conditions under which the agent may propose, approve, act, or must escalate to an accountable person.
- Time and transaction limits
- The duration, frequency, volume, and value boundaries within which authority remains valid.
- Stop and recovery
- The signals that suspend execution, the owner who can intervene, and the path to contain or reverse an unwanted change.
The enterprise-readiness framework places this envelope alongside evaluation, identity, evidence, incident response, and release authority so it can be examined as one production system.
Recommendation, approval, and action are different powers.
Many agent designs collapse three distinct stages into one word: automation. Boards and executives need the stages separated. The right degree of authority depends on workflow stakes, reversibility, data sensitivity, quality evidence, and the organization's risk tolerance—not on an industry-wide label for autonomy.
| Power | Agent may | Human authority | Evidence emphasis |
|---|---|---|---|
| Observe | Retrieve and organize permitted context | Sets access and purpose | Provenance, privacy, retrieval quality |
| Propose | Draft a recommendation or candidate action | Reviews consequential outputs | Accuracy, completeness, escalation quality |
| Prepare | Stage an action without committing it | Approves the transaction | Preview, validation, separation of duties |
| Act | Commit a bounded, permitted change | Owns the authority policy and exceptions | Identity, logs, limits, rollback, monitoring |
LockedIn Labs' forward-deployed engineers design these boundaries in the live workflow, where the real exceptions, system dependencies, and accountable operators are visible. The deployment model keeps authority expansion attached to explicit acceptance.
An agent earns authority through evidence, not confidence.
A production gate should answer whether the system is fit for the precise authority it is about to receive. Generic model scores can inform the decision, but they cannot substitute for workflow evaluations, access controls, operational tests, and a named owner empowered to say no.
The workflow and its material exceptions are mapped.
The team can show where context originates, where judgment enters, which systems change, and which people are affected.Evaluations reflect the deployment context.
Tests cover representative tasks, known failure modes, adversarial conditions, and the thresholds tied to each level of authority.Identity and permissions are enforceable.
The agent's principal, credentials, tool access, data scope, and revocation path are explicit and testable.Action evidence can be reconstructed.
Inputs, relevant context, model and policy versions, tool calls, approvals, outputs, and resulting state changes are observable at the level the workflow requires.Exceptions reach the right human authority.
Escalation is based on defined conditions, routed to an empowered owner, and exercised before launch—not left as a generic fallback.Containment and recovery are operational.
Teams can suspend execution, limit impact, restore an acceptable state where the workflow permits, and preserve the record needed for review.
NIST's AI Risk Management Framework describes governance as a cross-cutting, continual function; calls for documented roles, monitoring, and executive responsibility; and places an initial go/no-go decision after the system's context and impacts are mapped. See the NIST AI RMF Core.
Authority must be governed while the system is operating.
Launch changes the evidence available to the enterprise. Usage patterns shift. Upstream systems change. New exceptions appear. Adversarial behavior evolves. A control posture that was adequate for one scope may not support the next. Runtime evidence therefore feeds a continuing decision: retain, narrow, suspend, or expand authority.
NIST's cross-sector Generative AI Profile is a companion to the AI RMF for incorporating trustworthiness considerations into AI design, development, use, and evaluation. GAO's AI Accountability Framework organizes accountability around governance, data, performance, and monitoring, with questions for entities, auditors, and assessors. Together, these sources reinforce the practical point: authority is managed across a lifecycle, not conferred once.
In partner-led programs, the partner delivery model makes roles across the prime, platform, engineering team, and enterprise owner explicit so governance follows the integrated lifecycle.
Ask for the authority contract, the evidence, and the accountable owner.
The board does not need to operate the control plane. It does need assurance that management can state what authority exists, why it is appropriate, how performance and risk are observed, and who can intervene. These questions move the discussion from novelty to enterprise governance.
What exact business power is being delegated?
Name the workflow, systems, data, actions, limits, and affected stakeholders—not only the use-case label.Which decisions remain human decisions?
Identify approvals, exceptions, policy judgments, and release decisions that require accountable human authority.What evidence supports the current authority level?
Connect evaluation results and operating evidence to the specific permissions the agent receives.Who can stop the system, and what happens next?
Verify that containment, escalation, recovery, communication, and review have named owners.What would justify expansion—or require contraction?
Define the evidence and conditions that trigger a governed change in scope.