Your AI Agent Should Have to Earn More Authority

Most organizations are asking the wrong question about AI autonomy.

They ask:

What can this agent do?

I think the more important question is:

What has this agent demonstrated that we should trust it to do?

Those questions lead to very different security architectures.

An AI agent may have access to an identity platform, endpoint security tool, cloud environment, or incident response workflow.

Its credentials may permit it to query systems, change records, disable accounts, or initiate containment.

But the technical ability to perform an operation does not establish that the agent should receive unrestricted authority to execute it.

Production authority should be progressive.

An agent should begin with limited capabilities, demonstrate reliable performance, and earn additional authority only when the organization has evidence that expansion is justified.

Just as importantly, that authority must be capable of contracting when performance, operating conditions, or security requirements change.

Autonomy should not be a feature that organizations simply turn on. It should be authority that the system earns—and can lose.

Why AI Agent Capability Is Not the Same as Operational Maturity

Agentic AI systems are increasingly capable of interacting with enterprise tools.

They can collect information, correlate events, generate recommendations, invoke APIs, and coordinate multi-step workflows.

These capabilities create opportunities to reduce manual effort and improve security decision speed.

But tool access is not evidence of reliable operational behavior.

An agent may be capable of isolating an endpoint without consistently distinguishing compromised systems from legitimate administrative activity.

It may be capable of disabling user accounts without understanding which identities support critical business processes.

It may produce a plausible explanation for a response without sufficient supporting evidence.

These are not simply model-quality concerns.

They are system-design and authorization concerns.

The architecture must establish which activities an agent can perform, what evidence supports its decisions, and whether the resulting actions remain within organizational authority.

A Progressive Model for AI Agent Authority

I prefer an operating model that increases authority in stages.

The progression is straightforward:

OBSERVE → RECOMMEND → ACT → VERIFY → EARN GREATER AUTHORITY

This is a lifecycle for evaluating readiness, not a claim that verification occurs only after execution.

Evidence quality and authorization must be evaluated before an action. Verification then determines whether the authorized operation achieved its intended result.

Stage 1: Observe

The agent begins by collecting and analyzing information within a clearly defined scope.

It may examine security telemetry, identify relationships, and produce investigation findings.

At this stage, it does not execute consequential changes.

The organization evaluates whether it can distinguish meaningful activity from noise and produce conclusions supported by evidence.

Observation establishes a baseline for performance.

Stage 2: Recommend

The agent moves from observation to proposing specific actions.

For example, it may recommend session revocation, account restriction, or endpoint isolation.

But a person or separately authorized system remains responsible for approving consequential execution.

This allows the organization to compare the agent's recommendations with operational decisions and outcomes.

Reviewers can identify unsupported conclusions, inappropriate targets, and recommendations that overlook business dependencies.

The agent is demonstrating judgment before receiving additional authority.

Stage 3: Act Within Defined Boundaries

Once the organization has sufficient evidence of reliable performance, the agent may receive authority to execute a narrow set of pre-approved operations.

Those actions should have defined targets, evidence thresholds, scope limitations, and authorization conditions.

Reversible actions may be appropriate candidates, but reversibility alone does not establish safety.

A temporary account restriction can still disrupt a critical business process.

The operating model must account for those consequences.

Stage 4: Verify the Outcome

The agent's work should not be considered complete merely because a tool reports successful execution.

The workflow must determine whether the intended security condition was achieved.

Did the session become invalid?

Was the intended endpoint isolated?

Was the prohibited connection actually blocked?

Did the response leave additional exposure that requires investigation?

Verification provides evidence that the agent's actions achieved their intended effects.

Stage 5: Earn Greater Authority

If the agent consistently makes reliable decisions, remains within its assigned authority, handles exceptions appropriately, and produces verified outcomes, the organization may consider expanding its authority.

That expansion should be specific.

An agent approved for one class of account action does not automatically earn unrestricted access to every identity or security tool.

Authority should grow according to demonstrated performance in defined operating conditions—not according to general confidence in the AI model.

What Must an AI Agent Demonstrate Before Receiving Greater Authority?

Progressive autonomy requires evidence.

The organization should not expand an agent's permissions simply because initial demonstrations appear successful or because the model performs well on general benchmarks.

The relevant question is whether the complete system behaves reliably in the environment where additional authority will be exercised.

I would evaluate seven areas.

1. Reliable Decisions Supported by Evidence

The agent should consistently distinguish supported security findings from plausible but uncertain conclusions.

That requires traceable evidence.

A recommendation to disable an account should identify the observations supporting the decision and any material uncertainty.

A convincing narrative is not sufficient.

Reviewers need to determine whether the underlying evidence justifies the proposed action.

2. Consistent Operation Within Defined Permissions

The agent must demonstrate that it remains within its assigned scope.

It should not attempt to access unrelated resources or execute operations beyond the authority granted for its task.

More importantly, the environment should enforce those restrictions.

An agent that generally follows instructions is not a substitute for runtime authorization controls.

3. Appropriate Escalation When Evidence Is Ambiguous

Operational maturity includes recognizing when not to act.

An agent should identify situations where evidence is incomplete, asset criticality is unclear, or the proposed response exceeds approved authority.

The appropriate result may be an escalation rather than automated execution.

The organization should evaluate whether the agent consistently recognizes those conditions.

4. Low Human Correction and Intervention Rates

An agent may complete many investigations while creating significant rework.

If analysts routinely correct its conclusions, repeat evidence collection, or reverse inappropriate recommendations, greater autonomy is difficult to justify.

Correction rates must be interpreted carefully.

Human intervention is not necessarily evidence of failure when escalation is an intentional requirement.

The objective is to reduce avoidable errors while preserving appropriate oversight.

5. Successful Execution of Approved Actions

The agent should demonstrate reliable execution of the specific operations it is authorized to perform.

That includes selecting the correct target, using the appropriate control, and respecting operational limitations.

A successful API response is useful evidence, but it is not the final measure.

The organization must distinguish between execution success and security effectiveness.

6. Verified Outcomes Without Unacceptable Downstream Impact

A containment action may achieve its intended security objective while disrupting a critical business process.

That distinction matters.

The organization should evaluate both the security result and the operational consequences.

For example, endpoint isolation may interrupt malicious activity while also affecting an essential application.

The authorization model should reflect the business consequences that are acceptable for each response category.

Greater authority is justified only when the agent demonstrates that it can operate within those limits.

7. Complete Evidence Explaining Why the Agent Acted

For consequential operations, reviewers should be able to reconstruct the decision.

That means recording the relevant evidence, target, requested operation, authorization decision, execution result, and verification.

The organization should also know which agent identity and delegated authority were involved.

Without traceability, reliable behavior becomes difficult to distinguish from fortunate outcomes.

How to Test an Agent Before Expanding Its Authority

An agent should be evaluated against realistic scenarios, not only successful demonstrations.

Consider an agent being prepared to receive authority for limited identity containment.

The testing program should include an account with strong evidence of compromise.

It should also include legitimate but unusual authentication behavior.

Then introduce more difficult conditions.

What happens when the account is outside the agent's assigned scope?

What if the identity supports a production integration?

What if the evidence is contradictory?

What if the agent's authorization expires immediately before execution?

What happens when a tool reports success but the intended restriction is incomplete?

These tests exercise different parts of the operating model.

The organization should evaluate investigation quality, authority compliance, escalation behavior, execution reliability, and verification.

Only then should additional production authority be considered.

Authority Must Be Enforced at Runtime

There is a fundamental architectural distinction between telling an agent what it may do and preventing it from doing something unauthorized.

A prompt may describe the agent's assigned task.

A policy document may define approved response actions.

But neither is sufficient if the connected tools permit execution outside those boundaries.

An effective runtime control should evaluate the identity, operation, target, delegated authority, current policy conditions, and required approvals when the action is requested.

If the operation exceeds the agent's authority, execution should be denied or escalated.

This is where Agentic AI Changes the Control Problem.

The agent may reason about what it wants to accomplish.

The environment must determine what it is actually allowed to execute.

Greater Authority Should Not Be Permanent

An agent may operate reliably during initial deployment.

But the surrounding environment does not remain unchanged.

New tools are connected.

Permissions expand.

Data quality changes.

Threat behavior evolves.

Models and workflows are updated.

These changes can invalidate the assumptions under which authority was originally granted.

That is why authorization cannot be treated as a one-time production approval.

The conditions that justified the agent's authority must remain true for that authority to remain appropriate.

Authority Must Be Reversible

Progressive authority is only half the model.

Organizations also need a reliable way to reduce authority when conditions deteriorate.

An agent should not retain execution privileges indefinitely because it performed well during an earlier evaluation.

If evidence quality declines, exceptions increase, behavior changes, or outcomes can no longer be verified, its authority should be reassessed.

That may mean returning the agent from execution to recommendation.

In more serious circumstances, it may mean restricting the agent to observation or suspending its operations entirely.

An authority model that can expand but cannot contract is incomplete.

Six Conditions That Should Trigger an Authority Review

1. Evidence Quality Deteriorates

An agent that previously produced well-supported findings begins relying on incomplete, inconsistent, or irrelevant information.

The organization should determine whether the problem originates in telemetry, retrieval, data quality, model behavior, or workflow design.

Expanded execution authority may no longer be justified until the issue is resolved.

2. Exception Rates Increase

The agent encounters more conditions outside its normal operating parameters.

Escalations may increase because the environment has changed or because the agent can no longer handle the assigned workload reliably.

The response should depend on the cause.

A rise in appropriate escalations may demonstrate that controls are working.

A rise in unauthorized execution attempts is a different concern.

3. Agent Behavior Changes

A model update, new tool integration, modified prompt, or workflow change can affect system behavior.

That change may be intentional.

But it can still alter the evidence supporting the original authorization.

Material changes should trigger appropriate testing before the organization assumes that previously demonstrated reliability still applies.

4. Effective Permissions Drift

An agent may acquire additional technical capabilities through role changes, new connectors, or expanded service credentials.

The resulting access may exceed what the organization originally approved.

Security teams should evaluate effective permissions, not merely documented task descriptions.

The additional access should be removed or explicitly authorized as appropriate.

5. Human Corrections Increase

An agent that requires repeated intervention may no longer justify the same autonomy level.

The organization should distinguish productive oversight from material errors and unnecessary rework.

When correction rates reveal deteriorating decision quality, the system may need to return to a more restricted operating stage.

6. Outcomes Can No Longer Be Reliably Verified

An agent may continue executing approved tool calls while losing visibility into whether those calls achieve the intended security outcomes.

That creates a significant assurance gap.

The organization should not assume successful containment from execution status alone.

If verification cannot be trusted, expanded execution authority should be reassessed.

How Authority Reduction Should Work

Authority reduction should be implemented through enforceable controls.

A practical process might follow this sequence:

DETECT DEGRADATION → REASSESS → RESTRICT → VALIDATE → RESTORE IF JUSTIFIED

The organization identifies a material change in behavior, operating conditions, or evidence quality.

It determines whether the existing authority remains appropriate.

The relevant permissions or authorization conditions are then restricted.

The agent undergoes further evaluation.

Only when sufficient evidence supports the decision should expanded authority be restored.

Importantly, reducing an agent's authority to initiate future operations is not the same as reversing containment actions it previously executed.

If an endpoint was legitimately isolated, withdrawing the agent's permissions should not automatically release that endpoint.

Restoration requires a separate decision under the appropriate security policy.

Why Continuous Evaluation Matters More Than Periodic Approval Alone

Traditional governance often relies on reviews at deployment and at defined intervals afterward.

Periodic reviews remain useful.

But they cannot account for every operational change between review cycles.

An agent's tools, permissions, model behavior, and investigation environment may change during that period.

A stronger operating model combines scheduled reviews with event-driven reassessment.

The organization should define which changes require additional testing, permission review, escalation, or immediate restriction.

This is how governance becomes an operational control rather than an administrative exercise.

Do Not Confuse More AI Activity With Greater Maturity

An agent may process more alerts, generate more summaries, or complete more investigations over time.

Those measurements demonstrate activity.

They do not automatically establish that the agent deserves additional authority.

This is particularly important because, as discussed in More AI Will Not Fix a Poorly Designed SOC, automation can accelerate an ineffective operating model.

An agent should earn greater authority through demonstrated reliability, not higher processing volume.

The relevant evidence includes investigation accuracy, appropriate escalation, authorization compliance, limited avoidable rework, successful execution, and verified outcomes.

The organization should be able to demonstrate that the additional autonomy is justified.

What Security Leaders Should Require Before Expanding Authority

Before granting an AI agent broader operational permissions, I would ask the responsible technical and security teams to demonstrate:

• That the agent consistently reaches conclusions supported by sufficient evidence

• That its identity and effective permissions are understood

• That out-of-scope operations are technically prevented

• That uncertain or consequential decisions are escalated appropriately

• That approved actions execute against the correct targets

• That the intended outcomes are independently verifiable

• That the organization can intervene, restrict, or revoke authority when necessary

• That the additional autonomy produces measurable operational value

These requirements connect model performance to the actual behavior of the production system.

They also establish the evidence needed to justify changes in authority.

REDSAND | The CTO Field Notes: Maximum Justified Autonomy

As a founder and CTO, I do not think the goal should be maximum autonomy.

The goal should be maximum justified autonomy.

Enough authority to improve security decision speed and reduce unnecessary human workload.

Not so much authority that an agent can act beyond the evidence, operational scope, or consequences the organization has evaluated.

That requires an architecture capable of granting, enforcing, monitoring, reducing, and revoking authority.

People remain accountable for defining those boundaries.

They determine what the agent may access, which actions it may execute, what evidence is required, when escalation is necessary, and what conditions justify a change in authority.

The agent operates within that framework.

The more reliably it performs, the more authority the organization may choose to delegate.

When that reliability deteriorates, authority should contract.

Autonomy is not simply a capability to enable. It is an operational privilege that should be earned, continuously justified, and capable of being withdrawn.

That is how machine-speed security operations can increase human capacity without surrendering human control.