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.
Top comments (0)