Your AI Agent Has a Job but No Badge: The 2026 Authority System Every Business Needs

10 July 2026. At 08:42 on a Monday, a procurement agent receives a routine request to set up a new supplier. It reads the email, checks the contract, creates the supplier record and drafts the acknowledgement. Then it encounters new bank details in an attachment. The agent can update those details because it inherited a broad operations account. It can also release the first payment. The workflow is efficient right up to the moment somebody asks the decisive question: who gave this software authority to change where the money goes?

This is a realistic composite scenario built from common business-system patterns. It is not a claimed client case, and no result in this article should be read as a client result. The point is operational: an agent can perform every technical step correctly and still cross a business boundary it was never meant to cross.

The hard part of deploying agents is no longer simply getting a model to reason or call a tool. It is establishing AI agent identity and authorization in a form that security, operations, finance and process owners can all understand. A business needs to know which agent is acting, who owns it, what job it has been delegated, which systems and records it may touch, when a person must approve the next move, and how authority can be removed immediately.

SHOCKING

A shared service account can turn a well-designed agent into an ungoverned operator. The log may show that an API credential changed a supplier record, but not which agent instance used it, which instruction caused the action, whose authority the agent was exercising or whether that authority was valid at the time. The business has activity data without accountability.

This is why the NIST concept paper on software-agent identity and authority focuses on identification, authorization, auditing and non-repudiation. NIST also highlights the risks created when agents gain access to diverse datasets, tools and applications. Those are not remote technical concerns. They are the control questions behind changing a price, issuing a refund, releasing a purchase order, amending a customer record or sending a contractual communication.

The uncomfortable truth is that many agent pilots are authorised by architecture accident. The agent receives whatever the connector can access. Its job scope is described in a prompt. Approval means a message in a chat channel. Revocation means asking an engineer to find the right token. That is not delegated authority. It is ambient access with optimistic instructions.

TEXT HOOK

Treat every production agent as a temporary digital worker carrying a passport, a job card and a revocable power of attorney.

The passport is its unique agent identity. The job card defines the outcome and permitted scope. The power of attorney establishes the actions it may take on behalf of the organisation and the conditions under which that authority expires. None of the three should live only inside a system prompt.

This distinction matters because authentication and authorization answer different questions. Authentication proves which agent or workload is present. Authorization decides what that authenticated identity may do now, on this record, for this job, under these conditions. A valid identity without bounded authority is dangerous. A detailed policy without a verifiable identity is unenforceable.

ACHIEVEMENT

The target is not an agent that never encounters uncertainty. The target is a business system in which an agent can move quickly through ordinary work, stop cleanly at consequential decisions, produce evidence for every action and lose its authority in seconds when conditions change.

Demand for this capability is moving beyond technical teams. In OpenAI's June 2026 analysis of how agents are transforming work, OpenAI reported that 80.6% of sampled individual Codex users had made at least one request estimated to exceed 30 minutes of human work, 70.2% had made one estimated to exceed one hour, and 25.6% had made one estimated to exceed eight hours. These are OpenAI's own usage data, based on a random sample of 0.1% of users and model-estimated task horizons. OpenAI itself says the thresholds should be treated as directional rather than exact. They do not prove a return for your organisation. They do show why delegated work is becoming a control issue: longer-running tasks create more opportunities for agents to encounter sensitive data, changed conditions and decisions outside the original brief.

Your achievement should therefore be measured in controlled business performance: shorter cycle time without higher correction rates, fewer manual touches without weaker oversight, and more consistent policy execution without hiding exceptions.

Agent identity is a business control

Identity, authentication and authorization

Give each production agent a unique, non-human workload identity. Do not let several agents share one generic account, and do not let an agent operate under the personal credentials of the employee who commissioned it. A unique identity makes ownership, policy assignment, monitoring and revocation possible.

Authentication should use short-lived, machine-verifiable credentials issued to the runtime, not permanent secrets copied into prompts or configuration files. The runtime should prove both which agent is calling and which approved deployment is executing it. Version matters: a tested agent release and an experimental release should not silently inherit the same authority.

Authorization should combine role, job and context. A purchasing agent may be allowed to read approved supplier records, draft an order and submit it for approval. That does not mean it may alter bank details, approve its own order or export the full supplier database. The authority decision belongs at the tool gateway or policy-enforcement layer, where it cannot be negotiated away by natural-language instructions.

The emerging direction is visible in the NIST AI Agent Standards Initiative, which includes research into agent authentication and identity infrastructure for secure human-agent and multi-agent interaction. Standards will continue to evolve, but the operating principle is ready now: every action must resolve to a distinct identity and a current grant of authority.

Agent Authority Card

The Agent Authority Card is a concise, machine-readable operating contract for one agent in one business role. It sits above individual prompts and below corporate policy. A process owner can read it, a security team can enforce it, and an auditor can compare it with actual behaviour.

What the card must contain

• Identity: unique agent ID, runtime, approved version, authentication method and credential lifetime.
• Accountable owner: one named business owner and one technical custodian. A committee is not an owner.
• Job scope: the specific outcome, valid trigger, permitted start and stop conditions, and definition of completion.
• Allowed resources: named systems, data classes, record types, tools and operations.
• Explicit prohibitions: actions the agent must never take, even when requested by a user or another agent.
• Decision limits: value, risk, customer, geography, time and confidence conditions that narrow authority.
• Human approval boundary: events that require review, the authorised approver role and the evidence that must be presented.
• Delegation rules: whether the agent may call another agent, what authority may be passed and what may never be sub-delegated.
• Evidence requirements: events, inputs, policy decisions, approvals, outputs and system responses to retain in the agent audit trail.
• Exception route: how to pause, package context, assign an exception and resume or close the job.
• Revocation: kill-switch owner, credential disablement path, active-job handling and maximum time to remove access.
• Review and expiry: approval date, review date and automatic expiry. Authority should end unless deliberately renewed.

A card written for operators

Consider a supplier-onboarding agent. Its job is to collect required documents, validate mandatory fields, check a supplier against approved sources and prepare a record for review. It may create a draft supplier record. It may not change payment details on an existing supplier, approve the supplier, release a payment or contact a bank. A procurement manager approves the supplier; finance separately approves bank details through an established verification channel. The card makes that separation visible before the agent reaches a live system.

Keep the card close to the actual system architecture. If your digital systems AI landscape changes, the card must change with it. When an old application cannot support distinct workload identities or fine-grained permissions, treat that as a control gap in your legacy modernization plan, not as a reason to grant a shared administrator account.

Least privilege for a job, not a lifetime

Least privilege is often implemented as a narrow role that remains active indefinitely. Agents need a tighter model: minimum access for a particular job, for the minimum time, against the minimum data set, with the minimum permitted actions.

Use just-in-time authority

Begin each run with no business-system access. After the agent accepts a valid job, issue a short-lived grant derived from its Agent Authority Card and the job context. Narrow that grant to the relevant records where the system allows it. Expire it when the job completes, pauses beyond its permitted window or reaches an approval boundary.

Separate read, draft, submit, approve and execute permissions. Drafting a customer credit note is not the same authority as posting it. Preparing a contract amendment is not the same authority as sending or signing it. Searching a case is not the same authority as exporting every case. This action-level separation is where least privilege becomes operational rather than ceremonial.

For multi-agent work, never copy the parent agent's credential to a child. The parent delegates a bounded task; the child receives a new grant no broader than the intersection of its own card, the parent's delegable authority and the needs of that task.

The human approval boundary

A human approval boundary is the point at which machine preparation ends and accountable human judgement begins. It should be defined by business consequence, not by whether the model reports low confidence.

Place the boundary around irreversible consequences

Require approval for commitments that are financially material, legally binding, safety-related, externally visible, privacy-sensitive or difficult to reverse. Also require it when the agent proposes a new action pattern that was not tested, when trusted data sources disagree, or when the identity of the requesting party cannot be established.

The approval request should present the proposed action, business reason, source evidence, affected records, policy applied, alternatives considered and exact consequence of approval. A button labelled approve beside a model summary is not informed approval. The approver must see enough evidence to own the decision.

Prevent self-approval. An agent that prepares a payment must not satisfy the approval condition by calling an approval agent with equivalent authority. If a second agent performs verification, it may improve the evidence, but the accountable approval role remains human wherever the card says human judgement is required.

Delegation Control Loop

The Agent Authority Card states the standing rules. The Delegation Control Loop enforces them at runtime. It is the control cycle around every meaningful agent action, including actions delegated to another agent.

The seven runtime steps

• Bind: authenticate the agent instance, deployment version, requesting user or process, and job ID.
• Load: retrieve the current Agent Authority Card, job context, data classification and active policy version.
• Propose: require the agent to declare the intended tool, operation, target, purpose and expected effect before execution.
• Decide: allow, narrow, deny or route the action for approval using enforceable policy outside the model.
• Execute: use a short-lived grant through a controlled gateway, then capture the system response.
• Observe: write the agent audit trail, monitor outcome and compare actual effect with the proposed effect.
• Reconcile: continue, correct, escalate, revoke or close the job. Any delegated child task returns evidence and unused authority expires.

The loop is deliberately repetitive. An agent's plan can change when it sees new information, but its authority must be checked again when the proposed action changes. Approval of a plan is not blanket approval of every later tool call.

This approach aligns with the practical architecture described in OpenAI's business leader's guide to working with agents: models interpret and plan, tools provide access, and guardrails govern action. The Delegation Control Loop turns that broad idea into a business operating discipline with identity, policy decisions and evidence at every step.

Build an agent audit trail people can use

An agent audit trail should let an operator reconstruct a job without reading raw infrastructure logs. It must show who requested the work, which agent and version acted, what authority card and policy were active, which data and tools were used, what action was proposed, whether it was allowed, who approved it, what the destination system returned, and how the job ended.

Log decisions and effects, not hidden reasoning

Do not make private model reasoning the centre of the record. Capture the declared business rationale, relevant evidence, policy result and observable action. These are stable objects that reviewers can test. Prompts and model responses may also be retained when appropriate, but subject to data minimisation, security and retention rules.

Use correlation IDs across the agent runtime, policy engine, approval interface and destination system. Record timestamps consistently. Make logs append-only for sensitive actions, control access to them, and test whether a reviewer can retrieve one complete job history quickly. Auditability that requires several engineers and a week of log archaeology will fail when the first serious exception arrives.

OpenAI Frontier similarly frames agent identity and access management, explicit permissions, monitoring and detailed logs as enterprise governance capabilities. Product choice remains yours. The broader design requirement is independent of platform: authority and action must be visible and attributable.

Monitoring must connect behaviour to business

Availability monitoring tells you whether the agent is running. It does not tell you whether it is doing the right work. Monitor four layers together: technical health, policy compliance, task quality and business outcome.

What to watch in production

• Technical health: failed tool calls, latency, retries, queue age, credential errors and downstream outages.
• Authority health: denied actions, privilege requests, expired grants, unusual data access, approval bypass attempts and delegation depth.
• Task quality: completion rate, correction rate, evidence completeness, duplicate actions and exceptions by cause.
• Business effect: cycle time, manual touches, rework, service level, cost per completed case and value of prevented errors.

The 2026 NIST report on monitoring deployed AI systems describes monitoring as a fragmented field and separates functionality, operational, human-factors, security and compliance concerns, among others. That is a useful warning for operators: no single dashboard or accuracy score can represent production control.

Set alerts around changes in pattern, not just outright failures. A sudden rise in approval requests may indicate poor source data, a changed process or an overly narrow card. A sudden fall may indicate that an approval rule stopped firing. Both deserve investigation.

Revocation and the kill switch

Every production agent needs a tested kill switch. Pausing the user interface is insufficient if jobs, credentials or delegated agents continue running in the background.

Design revocation as a sequence

• Stop admission: block new jobs and new delegations for the agent identity.
• Revoke authority: invalidate active credentials, grants and approval tokens at the enforcement point.
• Contain work: pause active jobs before the next external action and identify child agents or scheduled tasks.
• Preserve evidence: retain logs, proposed actions, system responses and current state for investigation.
• Reconcile effects: identify actions already completed and decide which require reversal, notification or manual follow-up.
• Control restart: require an explicit owner decision, a documented cause and fresh credentials before resuming.

Test the kill switch in a realistic environment. Measure how long it takes to remove effective access, not how long it takes to click the button. Include nights, weekends and owner absence in the operating procedure.

Exception handling is the real workflow

Ordinary cases make a demo look good. Exceptions determine whether the agent belongs in a business system. Design the exception path before expanding automation.

Four exception classes

• Data exception: required information is missing, contradictory, stale or from an untrusted source. Pause and request evidence.
• Policy exception: the action is outside the card or needs a special waiver. Deny by default and route to the policy owner.
• System exception: a tool is unavailable or returns an uncertain result. Avoid blind retries where duplicate action is possible; reconcile first.
• Business exception: the case is valid but unusual, sensitive or consequential. Package the context for a named human role.

Every exception needs an owner, a response target, a safe holding state and a clear resume rule. The agent must not improvise a route around a blocked control. It should explain what stopped, what has and has not happened, and what decision is needed.

Measure business outcomes without theatre

Do not measure agent success by messages generated, tasks attempted or hours of theoretical labour. Establish a baseline from actual work, then compare controlled production performance over several cycles. OpenAI's guide also recommends baselining time, cost and accuracy and assessing improvement across multiple cycles rather than after one attempt.

The operator scorecard

• Outcome: percentage of eligible jobs completed to the defined business standard.
• Speed: median and slow-case cycle time from valid trigger to accepted completion.
• Quality: correction, rework, duplicate-action and reopened-case rates.
• Control: percentage of sensitive actions tied to a valid identity, current card and policy decision.
• Approval: approval volume, response time, rejection rate and cases where evidence was insufficient.
• Exceptions: rate by class, age, owner and recurring root cause.
• Authority: denied-action rate, privilege expansion requests, grant duration and successful revocation-test time.
• Economics: cost per accepted outcome, manual touches per case and capacity released for higher-value work.
• Experience: operator trust, reviewer workload and customer or supplier impact where relevant.

Agree definitions before the pilot. An agent can reduce handling time while creating more review work downstream. It can complete more cases while lowering first-time acceptance. The scorecard prevents a local efficiency metric from hiding a system-wide loss. For investments that need a finance-grade baseline, benefits logic and decision gate, connect the operating scorecard to CFOProof.

RECIPE

The production-readiness checklist

• Name one job: define the trigger, accepted output, stop condition and accountable process owner.
• Map consequences: list every read, write, communication, commitment and delegated action the job may require.
• Create the identity: issue a unique workload identity for the approved agent version.
• Write the Agent Authority Card: specify permissions, prohibitions, limits, expiry, approval and delegation rules.
• Place enforcement outside the model: apply authorization at the gateway, tool or destination-system layer.
• Draw the human approval boundary: identify consequential and unfamiliar actions that require accountable review.
• Implement the Delegation Control Loop: bind, load, propose, decide, execute, observe and reconcile every action.
• Instrument the agent audit trail: prove that one complete job can be reconstructed from request to outcome.
• Build exception queues: assign owners, response targets, holding states and resume conditions.
• Test revocation: stop new and active work, invalidate authority, find child tasks and preserve evidence.
• Baseline the process: record current cycle time, quality, manual effort, cost and exception patterns.
• Release in stages: observe first, then draft, then act within narrow limits, expanding only on measured evidence.

Use agent adoption research as a directional signal, not as your business case. Use practical agent guidance to inform team habits, not as a substitute for your own controls. Your evidence must come from your process, your risk appetite and your production data.

ROADMAP

This 90-day AI agent operating roadmap is designed to produce one controlled, measurable production workflow and a reusable authority pattern.

Days 1 to 30: define and contain

Select one high-volume job with a clear owner, observable output and manageable consequence. Map the current process, systems, data, exceptions and approvals. Establish the baseline. Create the unique agent identity and first Agent Authority Card. Build an observe-only version of the Delegation Control Loop that records what the agent would propose without allowing external writes.

Review proposed actions with frontline operators, security and the process owner. Tighten ambiguous scope. Confirm which destination systems can enforce distinct permissions. Define the kill-switch sequence and exception ownership before live action begins.

Days 31 to 60: act within narrow limits

Enable low-consequence actions with short-lived authority. Keep consequential writes behind the human approval boundary. Connect the audit trail across runtime, policy, approval and destination systems. Run exception drills for missing data, conflicting instructions, tool failure, duplicate requests, policy denial and credential revocation.

Review the scorecard weekly. Investigate both denied actions and unexpected absence of denials. Compare output quality and reviewer workload with the baseline. Do not expand scope to make the pilot look busier.

Days 61 to 90: prove and standardise

Run controlled production cycles, reconcile every material exception and test the kill switch under realistic conditions. Decide whether the outcome supports continuation, revision or retirement. Document the card template, policy patterns, approval interface, logging schema and release gate so the next agent starts from an operating standard.

Expand only one dimension at a time: more case volume, another action, another data class or another system. A broader grant across all dimensions makes it difficult to identify which change caused a control or performance shift.

FAQ

Does every AI agent need its own identity?

Every production agent that accesses business data, uses tools or takes action should have a distinct workload identity. Separate identities may also be appropriate for materially different roles or deployment versions of the same agent. The test is simple: can you attribute an action, apply a specific policy and revoke access without affecting unrelated work?

Can a human user's permissions simply pass to the agent?

Not by default. A person's access often covers many duties accumulated over time. The agent needs authority narrowed to the delegated job. Record the requesting human or process as context, but issue the agent its own short-lived grant. The effective permission should be no broader than the requester's authority, the agent's card and the job requirement.

Where should authorization rules live?

Keep natural-language guidance in the agent instructions, but enforce decisive rules outside the model in an identity provider, policy engine, tool gateway or destination system. The agent may explain why it wants an action. It should not be the final judge of whether that action is allowed.

What is the first sign that an agent is ready to scale?

Not a polished demonstration. Readiness appears when the agent produces accepted outcomes over repeated cycles, exceptions reach the right owners, sensitive actions carry complete evidence, revocation works, and the scorecard improves without shifting hidden work to reviewers. Scale the authority pattern only after those conditions are visible.

Practical CTA

Choose one agent that can currently read or write business data. Ask its owner to produce the identity, job scope, allowed actions, human approval boundary, agent audit trail, exception route and tested kill-switch procedure. If any answer exists only in a prompt, a diagram or one engineer's memory, the agent is not yet operating under controlled delegated authority.

Book an AI Agent Systems Review to map the Agent Authority Card, Delegation Control Loop, production controls and measurable business case for your first or next agent deployment.