9 min readHenry Thomas
AI agents are moving beyond answering questions.
They can write code, install packages, modify configuration files, interact with repositories, call APIs, access development tools, and execute shell commands.
That changes the enterprise security problem.
A command such as:
rm -rf ./build
may be harmless inside a temporary development environment.
A similar command executed against the wrong directory, production server, mounted volume, or privileged container could create a serious incident.
The important question for enterprises is therefore no longer simply:
“Can we detect dangerous prompts?”
It is:
“Should this AI-generated action be allowed to execute in this environment, on this resource, by this agent, under these permissions, right now?”
That is a runtime governance problem.
AI Agents Are Becoming Operators #
Traditional generative AI systems primarily produced text.
Modern AI agents can produce actions.
Coding agents and autonomous engineering systems increasingly interact with:
- shells and terminals
- source-code repositories
- files and directories
- package managers
- CI/CD pipelines
- cloud infrastructure
- databases
- APIs
- MCP servers
- internal development tools
- credentials and secrets
This creates a fundamentally different risk model.
When an AI assistant suggests a command, a human can review it before execution.
When an autonomous agent generates and executes the command itself, the enterprise must decide whether that action is authorized before it reaches the operating system.
The security boundary therefore needs to move closer to execution.
Prompt Filtering Is Not the Runtime Security Boundary #
Prompt security remains important.
Organizations should defend against prompt injection, malicious instructions, sensitive-data exposure, and manipulation of agent behavior.
But prompt filtering alone cannot determine whether an action should execute.
Consider:
npm install
That command looks ordinary.
But whether it should be allowed may depend on additional context.
Which package is being installed?
Which version?
Is the package approved?
Is the repository production-critical?
Does installation require external network access?
Could the package execute lifecycle scripts?
Is the agent operating inside a developer workstation, CI runner, sandbox, or production environment?
The command string alone does not provide enough information.
Enterprise AI security therefore requires more than classifying commands as simply “safe” or “dangerous.”
It requires contextual authorization.
Enterprises Need Runtime Authorization for AI Actions #
A practical model for governing AI-generated shell commands is:
Event → Context → Policy → Decision → Enforcement → Evidence
Each stage answers a different security question.
1. Event
First, the enterprise captures the proposed action.
For example:
terraform destroy
or:
curl https://example.com/script.sh | bash
or:
git push --force origin main
The command becomes an event that can be evaluated before execution.
2. Context
Next, the system determines the circumstances surrounding the action.
Context might include:
- agent identity
- human user identity
- organization or tenant
- repository
- branch
- working directory
- target host
- container
- environment
- command arguments
- requested privileges
- accessible credentials
- deployment stage
- related files
- network destination
- previous agent actions
This context can dramatically change the risk of a command.
For example:
rm -rf ./tmp/*
inside an isolated sandbox is very different from:
rm -rf /var/lib/*
on a production host.
The command category may be similar.
The risk is not.
3. Policy #
Once the proposed action and its context are understood, enterprise policy should determine what the agent is authorized to do.
Organizations can define rules such as:
- block destructive filesystem operations in production
- prevent force pushes to protected branches
- require approval before infrastructure destruction
- prohibit access to credential directories
- restrict outbound network connections
- allow only approved package registries
- block execution of downloaded scripts
- prevent privilege escalation
- limit commands available to specific agents
- restrict particular tools to approved environments
Policies can also vary by team, repository, environment, or workload.
A development agent working inside an ephemeral sandbox may receive broader permissions than an agent interacting with production infrastructure.
This is similar to traditional least-privilege security.
The difference is that AI agents may dynamically generate actions that were never explicitly programmed in advance.
4. Decision #
Runtime governance should convert policy evaluation into an explicit decision.
A useful model is:
Allow
The action satisfies policy and can execute automatically.
Block
The action violates policy and must not execute.
Require Approval
The action may be legitimate but requires human authorization.
Organizations may eventually introduce additional controls such as restricted execution or sandboxing, but the core principle remains the same:
AI proposes. Policy decides.
The agent should not be the final authority over its own permissions.
5. Enforcement #
A policy decision has little value if it cannot stop execution.
This is where enterprise AI governance must move beyond monitoring.
Security controls need an enforcement point between the AI agent and the systems it can affect.
For shell commands, that enforcement layer can evaluate commands before they reach the underlying execution environment.
The same architecture can eventually govern additional AI-generated actions, including:
- file modifications
- dependency installation
- Git operations
- API calls
- MCP tool invocations
- database operations
- cloud infrastructure changes
- CI/CD actions
The objective is not simply to observe what an AI agent did.
The objective is to prevent unauthorized actions before they happen.
6. Evidence #
Every decision should produce an auditable record.
An enterprise may need to answer questions such as:
- Which AI agent generated the command?
- Which user initiated the session?
- What command was proposed?
- What repository was involved?
- Which environment was targeted?
- Which policy evaluated the action?
- Was the command allowed or blocked?
- Did a human approve it?
- When did the event occur?
- What actions occurred immediately before and after it?
This evidence becomes important for security operations, compliance, incident response, internal investigations, and forensic reconstruction.
Traditional logs may show that a command executed.
AI runtime governance should explain why it was permitted to execute.
Dangerous Commands Are Only Part of the Problem #
Enterprises should avoid reducing AI shell security to a blacklist of commands.
Some commands are obviously high risk:
rm -rf /
Others become dangerous only in certain circumstances.
For example:
chmod 777
may be acceptable inside an isolated test fixture and unacceptable on a sensitive server.
Likewise:
git push --force
might be allowed on a disposable feature branch but blocked on a protected production branch.
The real security question is therefore not:
“Is this command dangerous?”
It is:
“Is this action authorized given the resource, identity, permissions, environment, and organizational policy involved?”
That distinction becomes increasingly important as AI agents gain access to more enterprise systems.
Least Privilege Must Extend to AI Agents #
Enterprises have spent decades applying least-privilege principles to users, applications, service accounts, and infrastructure.
AI agents should not become an exception.
An agent should receive only the capabilities required for its task.
That can include restrictions on:
- available commands
- accessible directories
- repositories
- branches
- credentials
- APIs
- databases
- cloud accounts
- network destinations
- tools
- environments
Organizations should also avoid giving every agent the same permission profile.
A coding assistant reviewing a pull request does not require the same privileges as a deployment agent modifying production infrastructure.
Agent identity and authorization should become first-class elements of enterprise security architecture.
Human Approval Should Focus on High-Risk Actions #
Requiring human approval for every AI-generated command defeats much of the value of automation.
Allowing every command creates the opposite problem.
Enterprises need a middle ground.
Low-risk, policy-compliant actions can execute automatically.
Clearly prohibited actions should be blocked automatically.
High-impact or ambiguous actions can be escalated for approval.
For example:
| AI Action | Possible Enterprise Policy |
|---|---|
| Run unit tests | Allow |
| Read repository files | Allow |
| Install an approved dependency | Allow |
| Install an unknown dependency | Review or block |
| Modify a protected configuration | Require approval |
| Force push to the main branch | Block |
| Delete cloud infrastructure | Require approval or block |
| Access credential directories | Block |
The goal is controlled autonomy.
Agents remain useful without becoming unrestricted operators.
Monitoring Alone Is Not Enough #
Many organizations begin AI governance by logging agent activity.
Visibility is valuable.
But visibility after execution does not prevent damage.
A dashboard showing that an autonomous agent executed a destructive command five minutes ago is useful for investigation.
It is not prevention.
For high-impact actions, enterprises need controls that operate in the execution path.
Runtime governance should be capable of making a policy decision before the command reaches the resource it can change.
What Enterprise AI Runtime Governance Should Provide #
As enterprises evaluate systems for governing AI-generated shell commands, several capabilities become increasingly important:
- real-time action interception
- context-aware policy evaluation
- agent and user identity attribution
- environment-aware rules
- allow and block policies
- human approval workflows
- least-privilege enforcement
- tenant and organization isolation
- dangerous-command detection
- secret and credential protection
- complete audit trails
- incident investigation evidence
- integration with engineering workflows
- policy enforcement before execution
Together, these capabilities create something enterprises historically have not needed:
an authorization layer for machine-generated actions.
The Enterprise Security Model Is Changing #
AI agents introduce a new category of actor inside enterprise systems.
They are not traditional users.
They are not static software applications.
And they are not merely chatbots.
They are dynamic software operators capable of generating new actions based on changing context.
That means existing controls remain necessary but may not be sufficient.
Identity controls who can access a system.
Application security protects software.
Endpoint security protects machines.
Cloud security protects infrastructure.
AI runtime governance addresses another question:
What should an AI agent be allowed to do once it has access?
As AI agents become more autonomous, this question will become increasingly important.
Oconee Runtime: Governing AI Actions Before Execution #
Oconee Runtime is building an AI governance layer for organizations deploying AI-powered development and agentic systems.
The objective is straightforward:
Give enterprises visibility and control over AI-generated actions before those actions create security, operational, or compliance incidents.
Instead of relying exclusively on prompt analysis, Oconee Runtime focuses on what agents actually attempt to do.
The model is:
Event → Context → Policy → Decision → Enforcement → Evidence
An AI agent can propose an action.
Enterprise policy determines whether that action is permitted.
The resulting decision creates evidence that security and compliance teams can review later.
As AI systems evolve from assistants into operators, enterprises will need security controls that evolve with them.
The future of enterprise AI security will not only be about controlling what AI can say.
It will be about controlling what AI can do.
Frequently Asked Questions
Can AI agents execute shell commands?
Yes. Many modern coding and engineering agents can invoke terminal tools, development environments, package managers, repositories, APIs, and other systems that ultimately allow them to execute commands or trigger operational actions.
Why aren’t prompt filters enough to secure AI agents?
Prompt filters evaluate inputs or generated content, but they may not have sufficient information about the resource, environment, permissions, identity, or operational impact associated with an action. Runtime authorization evaluates the proposed action in its actual execution context.
What is AI runtime governance?
AI runtime governance is the process of evaluating and enforcing organizational policies on actions proposed by AI systems while those systems are operating. Policies can determine whether an action should be allowed, blocked, or escalated for approval.
Should enterprises block all shell access for AI agents?
Not necessarily. Shell access can make coding and operational agents significantly more useful. Enterprises can instead apply least privilege, contextual policies, environment restrictions, human approvals, and runtime enforcement to control how that access is used.
How can enterprises audit commands generated by AI agents?
Organizations should capture the agent identity, user identity, proposed command, execution context, policy decision, environment, timestamp, approval information, and resulting action. This creates an audit trail that can support compliance, security investigations, and forensic analysis.
What is the difference between AI monitoring and AI enforcement?
Monitoring records what an AI agent does. Enforcement determines whether the agent is permitted to perform the action before it executes. Enterprise AI security increasingly requires both.
Related reading #
Background explainers on the subjects behind this post.
- Enterprise AI governance and action controlHow context-aware policy is applied to what AI tools and agents attempt to do, across browser and engineering workflows.
- News and field notesWhat we are shipping, and what we learn building enforcement for AI tools.
- Oconee Runtime pricingStarter, Growth, Growth+ and Enterprise — what each tier adds.
- What Belongs in an AI Audit TrailWhat belongs in an AI audit trail, and what should be left out?