Agentic AI Changes the Control Problem

REDSAND | THE CTO FIELD NOTES

By Tim Shelton | Founder & CTO, HAWK Network Defense

For the last two years, most AI conversations have focused on capability.

Can the model reason?

Can it write code?

Can it summarize documents?

Can it search internal knowledge?

Can it use tools?

Can it complete a workflow?

Those are useful questions.

But I think the more important enterprise question is starting to shift.

Not simply:

What can the AI do?

But:

What should it be allowed to do?

That distinction matters because agentic AI changes the control problem.

A chatbot can produce an answer.

An AI agent can take action.

It can call APIs, move data, create tickets, modify records, trigger workflows, recommend containment, and interact with systems that were originally designed for human users.

That means the risk is no longer just whether the model produces an incorrect answer.

The risk is what happens when an incorrect answer becomes an operational action.

A bad summary can create confusion.

A bad action can create business impact.

That is why I think many organizations are underestimating what changes when AI becomes agentic.

Why Traditional AI Governance Is Not Enough for Autonomous Agents

Traditional security and governance models were largely designed around humans, applications, and service accounts.

A human logs in.

A role defines what the person can access.

A system records the action.

A workflow routes approval.

A manager or control owner is accountable.

Agents do not always fit neatly into that operating model.

They may operate continuously.

They may act across multiple systems.

They may chain tools together.

They may re-plan based on changing context.

They may execute steps no one explicitly wrote into a fixed playbook.

They may act on behalf of a person, a team, a business process, or another system.

That creates a different control challenge.

Who is the actor?

Who granted the authority?

What intent is being executed?

What scope applies?

What data was used?

What systems were touched?

What decision did the agent influence?

What evidence supports the action?

What happens if the context changes?

And who owns the outcome?

Those questions cannot be answered by an acceptable-use policy alone.

They cannot be solved by writing "human in the loop" into a presentation.

They cannot be deferred entirely to audit logs after execution.

They have to be addressed at runtime.

That is the fundamental shift in agentic AI security architecture.

Agentic AI Governance Must Operate at Runtime

Agentic AI governance cannot live only in policy documents.

It has to show up at the moment the agent attempts to act.

A policy may establish that an agent is authorized to perform a specific function.

But the system still needs to determine whether the requested action is permitted under the current circumstances.

Can this agent perform this action?

Is the scope still valid?

Is the delegated authority still active?

Does the action require human approval?

Does the business context support it?

Is the evidence strong enough?

Is the potential blast radius acceptable?

Should the action be blocked, escalated, delayed, or allowed?

Those are runtime authorization questions.

They cannot be answered reliably through model instructions alone.

The environment needs enforceable controls capable of limiting what an agent can actually execute.

This is why the problem increasingly resembles operational security control design.

Identity.

Authorization.

Delegated authority.

Evidence.

Observability.

Escalation.

Revocation.

Containment.

Accountability.

These capabilities need to work together rather than operate as disconnected governance activities.

Capability Is Not Authority

An AI agent may have the technical capability to perform an action.

That does not mean the organization has authorized the action.

Consider an agent that has access to an enterprise API.

The API credentials may permit it to modify a record.

But does the agent have authority to make that modification for this business purpose, at this time, and under the current conditions?

Those are different questions.

Capability asks: Can the agent do this?

Authority asks: Should the agent be allowed to do this right now?

Effective security architecture must distinguish between them.

That means examining not only which tools and systems an agent can access, but also which actions are permitted, under what conditions, and with what limits.

Authorization should reflect the agent's purpose, delegated role, applicable policy, and potential consequences.

An approved use case should not automatically create permanent, unrestricted authority.

The ability to execute an action should remain subject to the controls that define whether the action is appropriate.

Why Prompts Cannot Replace Enforceable Security Boundaries

Instructions can guide an AI agent's behavior.

They can define goals, expected workflows, and preferred operating conditions.

But they are not a substitute for enforceable permissions.

An instruction saying an agent should not access sensitive information is not the same as preventing that access.

A policy stating that production changes require approval is not effective if the agent can execute those changes without the required authorization.

A requirement to escalate consequential decisions has limited value if the runtime environment permits unrestricted execution.

Security boundaries must exist in the systems and controls through which agents operate.

Policy defines what should happen. Runtime enforcement determines what the agent is actually permitted to do.

How Runtime Controls Govern AI Agent Actions

An effective runtime control model needs to evaluate more than the identity of the agent.

It should consider the requested action, available evidence, delegated authority, affected resources, and current operating conditions.

For consequential workflows, that means establishing:

• Which identity is requesting the action

• What business purpose the agent is serving

• Which tools, APIs, and data sources are permitted

• What permissions and authority apply

• Whether required evidence and decision thresholds have been satisfied

• Whether the action affects protected or business-critical systems

• Whether human approval is required

• Whether the action can be stopped or reversed

• What information must be preserved for review

The objective is not simply to monitor what the agent does.

It is to enforce what the agent may do before the action creates an unintended consequence.

Observability remains essential, but observing an unauthorized action after it occurs is not equivalent to preventing it.

Audit logs can explain what happened.

Runtime controls should help determine what is allowed to happen.

Both are necessary.

Human Oversight Should Be Built Into the Operating Model

One response to the risks of agentic AI is to require human approval before every action.

That may seem safer, but it can also eliminate much of the efficiency automation was intended to create.

Human control does not require every routine action to stop and wait for manual approval.

Organizations can define authority before an event occurs.

Routine, well-supported actions may be authorized within established boundaries.

Ambiguous or consequential actions may require escalation.

Actions outside the agent's authority should be blocked.

The important distinction is that human accountability remains in place even when individual actions are executed automatically.

People define the purpose, scope, permitted actions, escalation conditions, and requirements for intervention.

Technical controls enforce those decisions during execution.

That is how organizations can support useful autonomy without granting unrestricted authority.

Agentic AI Makes Security Operations a Critical Test Case

This is especially important in security operations.

An AI system that summarizes an alert is useful.

An AI system that recommends containment is more powerful.

An AI system that can initiate containment becomes part of the security response control plane.

At that point, the organization must know where automation ends and delegated authority begins.

Consider an agent that identifies a potentially compromised endpoint.

It may assemble evidence, correlate suspicious activity, and recommend isolation.

But before executing containment, the operating model must establish whether the action is permitted.

Is the endpoint part of a protected production environment?

Is the evidence sufficiently reliable?

Does the action meet a predefined response policy?

Could isolation create significant operational consequences?

Is the action reversible?

Does the situation require human escalation?

And how will the organization verify that containment succeeded?

Those questions should not be answered for the first time during an active incident.

Speed is valuable. But speed without control can create a different form of operational risk.

The objective is to reduce unnecessary delays while retaining enforceable boundaries around consequential actions.

Agentic AI Requires Continuous Authority Management

An agent may be appropriately authorized when it is initially deployed.

But enterprise environments do not remain static.

New tools are connected.

Permissions change.

Business processes evolve.

Additional data sources become available.

Credentials are rotated or expanded.

An agent's responsibilities may change.

Each change can alter what the agent is technically capable of accomplishing.

That means authority cannot be treated as a one-time configuration decision.

Organizations need to monitor whether the conditions that justified delegated authority remain valid.

If the environment changes materially, authority may need to be reassessed.

If an agent's behavior becomes unreliable or its permissions exceed its intended purpose, those permissions should be restricted.

If the agent encounters a condition beyond its approved scope, execution should be stopped or escalated.

A practical authority lifecycle is:

GRANT → ENFORCE → MONITOR → VERIFY → REASSESS → RESTRICT OR REVOKE

This makes authority an actively managed control rather than a permanent assumption.

What Enterprise AI Security Architecture Must Establish

I do not think the answer is to avoid agentic AI.

That would be the wrong lesson.

Agents can reduce repetitive work.

They can assemble evidence faster.

They can correlate signals across systems.

They can help analysts understand what happened.

They can prepare recommendations.

They can reduce the time between signal and action.

That is a real opportunity.

But the more operational authority agents receive, the more disciplined the security architecture needs to become.

Before allowing agents to execute consequential business processes, organizations should be able to answer several questions.

Identity and Scope

Can the organization identify the agent, the purpose it serves, and the resources it is permitted to access?

Authorization and Enforcement

Are delegated permissions technically enforceable at the moment an action is requested?

Evidence and Decision Quality

Can the organization establish why an action was recommended or executed, and what evidence supported the determination?

Escalation and Revocation

Can the agent recognize conditions outside its authority? Can the organization stop execution, reduce permissions, or revoke authority?

Verification and Accountability

Can the organization verify the outcome, reconstruct what occurred, and identify who owns the resulting business consequences?

These are foundational questions for deploying autonomous systems responsibly.

They connect technical capability to organizational control.

REDSAND | The CTO Field Notes

I think the next generation of AI governance will be defined increasingly by control at the point of action.

Not just better prompts.

Not just better models.

Not just better policies.

Better runtime enforcement.

More reliable evidence.

Clearer delegated authority.

Stronger observability.

Defined escalation paths.

And accountability that remains intact as systems become more autonomous.

Agents should not inherit open-ended trust simply because they are useful.

They should not be able to act merely because a use case was approved once.

And they should not be governed only after execution has occurred.

Capability asks what an agent can do.

Authority determines what it should be allowed to do.

Those are not the same question.

Agentic AI does not just change what machines can do.

It changes what organizations must be able to govern.

The future of agentic AI security will depend on whether organizations can enforce what their agents are authorized to do.

Tim Shelton
Founder & CTO | HAWK Network Defense

REDSAND | THE CTO FIELD NOTES — AI security architecture, runtime enforcement, autonomous systems, and machine-speed security operations.