Policy enforcement for browser AI and coding agents
10 min readHenry Thomas
For the first wave of generative AI adoption, enterprise security largely focused on what went into and came out of the model.
Was the prompt safe?
Did it contain sensitive data?
Did the response expose something it shouldn’t?
Those remain important questions. But AI systems are rapidly moving beyond the prompt-and-response model.
Coding agents and AI-assisted development tools can execute shell commands, modify files, install dependencies, interact with repositories, invoke external tools, access credentials, and participate in workflows that produce real changes to enterprise systems.
The security question is changing with them.
It is no longer enough to ask:
“Was the prompt safe?”
Organizations increasingly need to ask:
“Should this agent be allowed to take this action, against this resource, in this context?”
That distinction is one of the problems we’re working on with Oconee Runtime.
⸻
AI Has Moved From Generating to Acting
Traditional generative AI interactions were relatively simple:
User → Prompt → Model → Response
Security controls could focus heavily on the information crossing the model boundary.
Detect a credential before someone pastes it into ChatGPT.
Identify sensitive source code.
Warn when a prompt contains regulated information.
Record AI usage for auditing.
Those controls are still necessary.
But an agentic workflow can look very different:
User → Intent → Agent → Reasoning → Tool → Action → Resource
The response is no longer necessarily the end of the interaction.
It can be the beginning of execution.
A coding agent might determine that completing a task requires it to:
- modify several source files;
- install a new package;
- execute a shell command;
- read configuration files;
- interact with a repository;
- call an external tool;
- or perform a sequence of several actions.
This isn’t hypothetical behavior at the edge of AI development. OWASP’s current secure-coding guidance describes agentic coding tools as capable of executing commands, installing packages, editing files, running tests, accessing networks and operating on repositories.
Once models can initiate actions, organizations have a different security problem.
AI safety becomes partly an authorization problem.
⸻
A Safe Prompt Does Not Guarantee a Safe Execution Path
Consider a perfectly reasonable prompt:
Fix the dependency issue in this project and run the tests.
Nothing about that request is obviously malicious.
An agent might inspect the repository, determine that a dependency needs to change, modify a package manifest, install packages and execute tests.
That may be exactly what the developer wanted.
But the same reasoning process could also result in an unexpected command, access to a sensitive file, modification of a protected resource or use of a tool that shouldn’t be available in that environment.
The original prompt can therefore be completely legitimate while an individual action later in the execution path is inappropriate.
That creates an important distinction:
Prompt safety evaluates the request.
Action authorization evaluates what the system is actually about to do.
Enterprises increasingly need both.
⸻
The Authorization Decision Needs More Context
Traditional permissions often ask questions like:
Does this user have access to this repository?
Agentic systems introduce additional dimensions.
The relevant decision may become:
Who initiated the task?
Which agent is acting?
What action is being attempted?
What resource is being targeted?
What environment is involved?
What has already happened during this session?
What organizational policy applies?
What is the risk of allowing the action right now?
This can be represented conceptually as:
Actor → Agent → Action → Resource → Context → Policy → Decision
The important part is context.
The same action should not necessarily receive the same decision everywhere.
⸻
Same Action. Different Context. Different Policy.
Imagine an AI coding agent wants to perform an action in a developer’s scratch repository.
An organization might decide that the action is acceptable but worth surfacing:
Development repository
→ Action proposed → Policy evaluated → WARN
Now imagine a similar class of action involving a critical production repository.
The organization may want a different result:
Critical repository
→ Action proposed → Policy evaluated → BLOCK
The action didn’t necessarily change.
The context did.
That’s why binary allowlists alone are unlikely to cover every enterprise agent workflow.
Organizations may need policies capable of considering the relationship between the actor, agent, action, target resource and operating context before determining what happens next.
⸻
Why Allow, Warn and Block?
Not every risky action should be blocked.
Security systems that block too aggressively eventually create pressure to bypass them.
At the same time, simply logging everything doesn’t provide meaningful control.
We think there is useful space between those extremes.
ALLOW
The action conforms to policy.
Execution proceeds and the event can be recorded for visibility and audit purposes.
WARN
The action presents enough risk or uncertainty to warrant visibility, but policy does not require outright prevention.
The user can be informed and the event recorded.
BLOCK
The proposed action violates policy strongly enough that execution should be prevented at the supported enforcement point.
This produces a more useful governance model than treating every event as either completely acceptable or completely forbidden.
The goal isn’t:
Block AI.
It’s:
Give organizations control over how AI operates in their environments.
⸻
Policy Should Live Outside the Agent
There’s another architectural issue here.
An AI agent shouldn’t be responsible for deciding whether its own behavior complies with enterprise policy.
You can tell an agent:
Don’t execute dangerous commands.
That instruction is useful.
But it isn’t the same thing as an independent security control.
The model is still reasoning about both the task and the restriction.
A stronger pattern separates them:
AI proposes. Policy decides.
Conceptually:
┌─────────────────┐
│ AI / Agent │
└────────┬────────┘
│
Proposed Action
│
▼
┌─────────────────┐
│ Policy Boundary │
└────────┬────────┘
│
Context + Policy Evaluation
│
┌───────────┼───────────┐
▼ ▼ ▼
ALLOW WARN BLOCK
│ │
└─────┬─────┘
▼
Execution
│
▼
Evidence / Audit
The agent proposes what it wants to do.
An independent mechanism evaluates the proposed action according to organizational policy.
That separation matters because:
Agent intelligence does not imply agent authority.
Current security work is increasingly moving in this direction. OWASP guidance recommends separating agent decision-making from execution for high-impact actions and independently validating scope, privilege and approval before execution.
⸻
Authorization Is Becoming a First-Class Agent Security Problem
This isn’t just an Oconee thesis.
The broader security ecosystem is beginning to focus directly on agent identity, authority and runtime controls.
In February 2026, NIST launched an AI Agent Standards Initiative aimed at helping agents operate securely on behalf of users and interoperate across the emerging ecosystem.
NIST has also specifically explored software and AI-agent identity and authorization. Its concept work raises questions around least privilege, dynamic authorization as context changes, delegation, human identity, agent identity, auditing and mechanisms for an agent to demonstrate authority to perform a particular action.
More recently, NIST described model-only guardrails as insufficient for some of the security challenges created by agentic systems and highlighted the need for more granular authorization as agents operate across enterprise resources.
The standardization landscape is also evolving quickly. OWASP’s newly published Agent Control Standard describes runtime middleware hooks through which safety policies can be applied across agent frameworks.
That’s encouraging.
But it also shows how early this architecture remains.
There isn’t yet one universally adopted authorization layer governing every browser AI tool, coding agent, IDE workflow, MCP tool and enterprise AI system.
Organizations are assembling pieces from existing identity systems, application permissions, sandboxing, policy engines, agent-specific controls and new standards.
That makes interoperability and independent enforcement increasingly important.
⸻
Browser AI Creates a Related Problem
Coding agents are only one part of the picture.
Organizations also have employees using browser-based AI applications every day.
Source code can be pasted into an AI interface.
Credentials can accidentally enter prompts.
Customer information can be submitted to external models.
Sensitive documents can move into AI workflows.
The browser therefore remains an important governance surface.
But browser governance and agent governance shouldn’t necessarily become two completely disconnected security programs.
From the organization’s perspective, both are manifestations of the same larger question:
How is AI interacting with our people, data, tools and resources?
That is why we’re approaching Oconee Runtime across multiple AI surfaces rather than treating browser AI and coding-agent activity as unrelated problems.
⸻
Visibility Is Necessary. Control Is the Next Layer.
Observability matters.
Organizations need to know:
- which AI systems are being used;
- what risky activity is occurring;
- what policies are being triggered;
- which resources are involved;
- what actions agents attempt;
- and what happened during an incident.
But visibility answers:
What happened?
Governance introduces another question:
What should have been allowed to happen?
And enforcement adds:
Can we prevent something that violates policy before the supported action executes?
Those capabilities form a progression:
Observe → Understand → Evaluate → Enforce → Prove
This is where we think AI governance needs to evolve.
Not away from observability.
Beyond observability.
⸻
Enforcement Also Needs Evidence
Preventing an action isn’t enough for an enterprise security system.
The organization should be able to understand why the decision happened.
A useful governance record might include:
Actor Who initiated the workflow?
Agent What AI system was operating?
Action What was being attempted?
Resource What would the action affect?
Context What environment and circumstances applied?
Policy Which organizational rule was evaluated?
Decision Was the action allowed, warned or blocked?
Evidence What can security or engineering review afterward?
That gives us another useful abstraction:
Actor → Agent → Action → Resource → Context → Policy → Decision → Evidence
This evidence becomes valuable for security investigations, engineering reviews, governance reporting and auditability.
It also makes policy tuning possible.
If a security team sees hundreds of unnecessary warnings, policies can be adjusted.
If a supposedly low-risk workflow repeatedly attempts unexpected actions, the organization has something concrete to investigate.
Governance becomes a feedback loop rather than a static set of rules.
⸻
What We’re Building With Oconee Runtime
Oconee Runtime is our attempt to build governance infrastructure around these changing AI workflows.
Today, we’re focused on visibility, policy and enforcement across supported browser AI, IDE and coding-agent workflows.
That includes capabilities around:
Browser AI governance
Visibility and policy controls around interactions with browser-based AI tools, including sensitive-data detection and policy enforcement.
Engineering workflow governance
Visibility into AI-assisted development activity and supported IDE workflows.
Coding-agent governance
Controls around supported agent actions such as command execution, file activity and repository context.
Context-aware policy
The ability to apply different decisions based on organizational policy and relevant context.
Enforcement
ALLOW, WARN and BLOCK decisions at supported enforcement points.
Audit visibility
A record security and engineering teams can use to understand policy events and investigate activity.
The objective isn’t to replace the AI tools developers want to use.
And it isn’t to put a human approval dialog in front of every agent action.
We’re trying to answer a more fundamental question:
How can organizations let AI become more capable without giving it unlimited authority?
⸻
This Is Still an Emerging Security Boundary
There are plenty of hard questions left.
Where should enforcement happen?
How should agent identity work across systems?
How should delegated human authority be represented?
When should authorization expire?
How should policies account for a sequence of individually harmless actions that becomes risky in aggregate?
Which decisions should require human approval?
When should systems fail closed?
How should authorization work across MCP and other external tools?
How should policy context move between agents?
How much evidence should organizations retain without collecting unnecessary sensitive data?
How do we create strong controls without destroying the productivity benefits that made organizations adopt agents in the first place?
The industry does not have final answers to all of these questions.
That’s precisely why this is an interesting time to work on the problem.
Standards efforts are accelerating, security guidance is becoming more concrete, and enterprises are moving agents into real workflows simultaneously.
The architecture is being defined while the technology is being deployed.
⸻
The Security Boundary Is Moving
The first generation of enterprise AI security was understandably centered on models, prompts and responses.
The next generation has to account for something different:
AI systems that can act.
When software can reason about a task, select tools and initiate actions against enterprise resources, security can’t stop at determining whether the original prompt looked safe.
We also need to determine whether the resulting authority is appropriate.
That means thinking about:
identity
actions
resources
context
policy
authorization
enforcement
evidence
The goal shouldn’t be to prevent agents from becoming powerful.
The goal should be to make increasing capability compatible with enterprise control.
Because the more capable agents become, the more important this distinction becomes:
An agent’s ability to perform an action does not mean it should have the authority to perform it.
Or, put more simply:
AI proposes. Policy decides.
We’re building toward that model with Oconee Runtime.
Explore Oconee Runtime