{"slug": "show-hn-oconee-runtime-policy-enforcement-for-browser-ai-and-coding-agents", "title": "Show HN: Oconee Runtime – Policy enforcement for browser AI and coding agents", "summary": "Oconee Runtime, a new open-source project by Henry Thomas, provides policy enforcement for browser AI and coding agents, addressing the shift from prompt-based AI to agentic systems that execute actions. The runtime evaluates authorization decisions based on actor, agent, action, resource, and context, rather than just prompt safety, to prevent unintended or harmful actions in enterprise environments.", "body_md": "# Policy enforcement for browser AI and coding agents\n\n10 min read Henry Thomas\n\nFor the first wave of generative AI adoption, enterprise security largely focused on what went into and came out of the model.\n\nWas the prompt safe?\n\nDid it contain sensitive data?\n\nDid the response expose something it shouldn’t?\n\nThose remain important questions. But AI systems are rapidly moving beyond the prompt-and-response model.\n\nCoding 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.\n\nThe security question is changing with them.\n\nIt is no longer enough to ask:\n\n“Was the prompt safe?”\n\nOrganizations increasingly need to ask:\n\n“Should this agent be allowed to take this action, against this resource, in this context?”\n\nThat distinction is one of the problems we’re working on with Oconee Runtime.\n\n⸻\n\nAI Has Moved From Generating to Acting\n\nTraditional generative AI interactions were relatively simple:\n\nUser → Prompt → Model → Response\n\nSecurity controls could focus heavily on the information crossing the model boundary.\n\nDetect a credential before someone pastes it into ChatGPT.\n\nIdentify sensitive source code.\n\nWarn when a prompt contains regulated information.\n\nRecord AI usage for auditing.\n\nThose controls are still necessary.\n\nBut an agentic workflow can look very different:\n\nUser → Intent → Agent → Reasoning → Tool → Action → Resource\n\nThe response is no longer necessarily the end of the interaction.\n\nIt can be the beginning of execution.\n\nA coding agent might determine that completing a task requires it to:\n\n- modify several source files;\n- install a new package;\n- execute a shell command;\n- read configuration files;\n- interact with a repository;\n- call an external tool;\n- or perform a sequence of several actions.\n\nThis 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.\n\nOnce models can initiate actions, organizations have a different security problem.\n\nAI safety becomes partly an authorization problem.\n\n⸻\n\nA Safe Prompt Does Not Guarantee a Safe Execution Path\n\nConsider a perfectly reasonable prompt:\n\nFix the dependency issue in this project and run the tests.\n\nNothing about that request is obviously malicious.\n\nAn agent might inspect the repository, determine that a dependency needs to change, modify a package manifest, install packages and execute tests.\n\nThat may be exactly what the developer wanted.\n\nBut 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.\n\nThe original prompt can therefore be completely legitimate while an individual action later in the execution path is inappropriate.\n\nThat creates an important distinction:\n\nPrompt safety evaluates the request.\n\nAction authorization evaluates what the system is actually about to do.\n\nEnterprises increasingly need both.\n\n⸻\n\nThe Authorization Decision Needs More Context\n\nTraditional permissions often ask questions like:\n\nDoes this user have access to this repository?\n\nAgentic systems introduce additional dimensions.\n\nThe relevant decision may become:\n\nWho initiated the task?\n\nWhich agent is acting?\n\nWhat action is being attempted?\n\nWhat resource is being targeted?\n\nWhat environment is involved?\n\nWhat has already happened during this session?\n\nWhat organizational policy applies?\n\nWhat is the risk of allowing the action right now?\n\nThis can be represented conceptually as:\n\nActor → Agent → Action → Resource → Context → Policy → Decision\n\nThe important part is context.\n\nThe same action should not necessarily receive the same decision everywhere.\n\n⸻\n\nSame Action. Different Context. Different Policy.\n\nImagine an AI coding agent wants to perform an action in a developer’s scratch repository.\n\nAn organization might decide that the action is acceptable but worth surfacing:\n\nDevelopment repository\n\n→ Action proposed → Policy evaluated → WARN\n\nNow imagine a similar class of action involving a critical production repository.\n\nThe organization may want a different result:\n\nCritical repository\n\n→ Action proposed → Policy evaluated → BLOCK\n\nThe action didn’t necessarily change.\n\nThe context did.\n\nThat’s why binary allowlists alone are unlikely to cover every enterprise agent workflow.\n\nOrganizations may need policies capable of considering the relationship between the actor, agent, action, target resource and operating context before determining what happens next.\n\n⸻\n\nWhy Allow, Warn and Block?\n\nNot every risky action should be blocked.\n\nSecurity systems that block too aggressively eventually create pressure to bypass them.\n\nAt the same time, simply logging everything doesn’t provide meaningful control.\n\nWe think there is useful space between those extremes.\n\nALLOW\n\nThe action conforms to policy.\n\nExecution proceeds and the event can be recorded for visibility and audit purposes.\n\nWARN\n\nThe action presents enough risk or uncertainty to warrant visibility, but policy does not require outright prevention.\n\nThe user can be informed and the event recorded.\n\nBLOCK\n\nThe proposed action violates policy strongly enough that execution should be prevented at the supported enforcement point.\n\nThis produces a more useful governance model than treating every event as either completely acceptable or completely forbidden.\n\nThe goal isn’t:\n\nBlock AI.\n\nIt’s:\n\nGive organizations control over how AI operates in their environments.\n\n⸻\n\nPolicy Should Live Outside the Agent\n\nThere’s another architectural issue here.\n\nAn AI agent shouldn’t be responsible for deciding whether its own behavior complies with enterprise policy.\n\nYou can tell an agent:\n\nDon’t execute dangerous commands.\n\nThat instruction is useful.\n\nBut it isn’t the same thing as an independent security control.\n\nThe model is still reasoning about both the task and the restriction.\n\nA stronger pattern separates them:\n\nAI proposes. Policy decides.\n\nConceptually:\n\n```\n         ┌─────────────────┐\n         │    AI / Agent   │\n         └────────┬────────┘\n                  │\n           Proposed Action\n                  │\n                  ▼\n         ┌─────────────────┐\n         │ Policy Boundary │\n         └────────┬────────┘\n                  │\n       Context + Policy Evaluation\n                  │\n      ┌───────────┼───────────┐\n      ▼           ▼           ▼\n    ALLOW        WARN        BLOCK\n      │           │\n      └─────┬─────┘\n            ▼\n         Execution\n            │\n            ▼\n    Evidence / Audit\n```\n\nThe agent proposes what it wants to do.\n\nAn independent mechanism evaluates the proposed action according to organizational policy.\n\nThat separation matters because:\n\nAgent intelligence does not imply agent authority.\n\nCurrent 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.\n\n⸻\n\nAuthorization Is Becoming a First-Class Agent Security Problem\n\nThis isn’t just an Oconee thesis.\n\nThe broader security ecosystem is beginning to focus directly on agent identity, authority and runtime controls.\n\nIn 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.\n\nNIST 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.\n\nMore 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.\n\nThe 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.\n\nThat’s encouraging.\n\nBut it also shows how early this architecture remains.\n\nThere isn’t yet one universally adopted authorization layer governing every browser AI tool, coding agent, IDE workflow, MCP tool and enterprise AI system.\n\nOrganizations are assembling pieces from existing identity systems, application permissions, sandboxing, policy engines, agent-specific controls and new standards.\n\nThat makes interoperability and independent enforcement increasingly important.\n\n⸻\n\nBrowser AI Creates a Related Problem\n\nCoding agents are only one part of the picture.\n\nOrganizations also have employees using browser-based AI applications every day.\n\nSource code can be pasted into an AI interface.\n\nCredentials can accidentally enter prompts.\n\nCustomer information can be submitted to external models.\n\nSensitive documents can move into AI workflows.\n\nThe browser therefore remains an important governance surface.\n\nBut browser governance and agent governance shouldn’t necessarily become two completely disconnected security programs.\n\nFrom the organization’s perspective, both are manifestations of the same larger question:\n\nHow is AI interacting with our people, data, tools and resources?\n\nThat is why we’re approaching Oconee Runtime across multiple AI surfaces rather than treating browser AI and coding-agent activity as unrelated problems.\n\n⸻\n\nVisibility Is Necessary. Control Is the Next Layer.\n\nObservability matters.\n\nOrganizations need to know:\n\n- which AI systems are being used;\n- what risky activity is occurring;\n- what policies are being triggered;\n- which resources are involved;\n- what actions agents attempt;\n- and what happened during an incident.\n\nBut visibility answers:\n\nWhat happened?\n\nGovernance introduces another question:\n\nWhat should have been allowed to happen?\n\nAnd enforcement adds:\n\nCan we prevent something that violates policy before the supported action executes?\n\nThose capabilities form a progression:\n\nObserve → Understand → Evaluate → Enforce → Prove\n\nThis is where we think AI governance needs to evolve.\n\nNot away from observability.\n\nBeyond observability.\n\n⸻\n\nEnforcement Also Needs Evidence\n\nPreventing an action isn’t enough for an enterprise security system.\n\nThe organization should be able to understand why the decision happened.\n\nA useful governance record might include:\n\nActor Who initiated the workflow?\n\nAgent What AI system was operating?\n\nAction What was being attempted?\n\nResource What would the action affect?\n\nContext What environment and circumstances applied?\n\nPolicy Which organizational rule was evaluated?\n\nDecision Was the action allowed, warned or blocked?\n\nEvidence What can security or engineering review afterward?\n\nThat gives us another useful abstraction:\n\nActor → Agent → Action → Resource → Context → Policy → Decision → Evidence\n\nThis evidence becomes valuable for security investigations, engineering reviews, governance reporting and auditability.\n\nIt also makes policy tuning possible.\n\nIf a security team sees hundreds of unnecessary warnings, policies can be adjusted.\n\nIf a supposedly low-risk workflow repeatedly attempts unexpected actions, the organization has something concrete to investigate.\n\nGovernance becomes a feedback loop rather than a static set of rules.\n\n⸻\n\nWhat We’re Building With Oconee Runtime\n\nOconee Runtime is our attempt to build governance infrastructure around these changing AI workflows.\n\nToday, we’re focused on visibility, policy and enforcement across supported browser AI, IDE and coding-agent workflows.\n\nThat includes capabilities around:\n\nBrowser AI governance\n\nVisibility and policy controls around interactions with browser-based AI tools, including sensitive-data detection and policy enforcement.\n\nEngineering workflow governance\n\nVisibility into AI-assisted development activity and supported IDE workflows.\n\nCoding-agent governance\n\nControls around supported agent actions such as command execution, file activity and repository context.\n\nContext-aware policy\n\nThe ability to apply different decisions based on organizational policy and relevant context.\n\nEnforcement\n\nALLOW, WARN and BLOCK decisions at supported enforcement points.\n\nAudit visibility\n\nA record security and engineering teams can use to understand policy events and investigate activity.\n\nThe objective isn’t to replace the AI tools developers want to use.\n\nAnd it isn’t to put a human approval dialog in front of every agent action.\n\nWe’re trying to answer a more fundamental question:\n\nHow can organizations let AI become more capable without giving it unlimited authority?\n\n⸻\n\nThis Is Still an Emerging Security Boundary\n\nThere are plenty of hard questions left.\n\nWhere should enforcement happen?\n\nHow should agent identity work across systems?\n\nHow should delegated human authority be represented?\n\nWhen should authorization expire?\n\nHow should policies account for a sequence of individually harmless actions that becomes risky in aggregate?\n\nWhich decisions should require human approval?\n\nWhen should systems fail closed?\n\nHow should authorization work across MCP and other external tools?\n\nHow should policy context move between agents?\n\nHow much evidence should organizations retain without collecting unnecessary sensitive data?\n\nHow do we create strong controls without destroying the productivity benefits that made organizations adopt agents in the first place?\n\nThe industry does not have final answers to all of these questions.\n\nThat’s precisely why this is an interesting time to work on the problem.\n\nStandards efforts are accelerating, security guidance is becoming more concrete, and enterprises are moving agents into real workflows simultaneously.\n\nThe architecture is being defined while the technology is being deployed.\n\n⸻\n\nThe Security Boundary Is Moving\n\nThe first generation of enterprise AI security was understandably centered on models, prompts and responses.\n\nThe next generation has to account for something different:\n\nAI systems that can act.\n\nWhen 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.\n\nWe also need to determine whether the resulting authority is appropriate.\n\nThat means thinking about:\n\nidentity\n\nactions\n\nresources\n\ncontext\n\npolicy\n\nauthorization\n\nenforcement\n\nevidence\n\nThe goal shouldn’t be to prevent agents from becoming powerful.\n\nThe goal should be to make increasing capability compatible with enterprise control.\n\nBecause the more capable agents become, the more important this distinction becomes:\n\nAn agent’s ability to perform an action does not mean it should have the authority to perform it.\n\nOr, put more simply:\n\nAI proposes. Policy decides.\n\nWe’re building toward that model with Oconee Runtime.\n\nExplore Oconee Runtime", "url": "https://wpnews.pro/news/show-hn-oconee-runtime-policy-enforcement-for-browser-ai-and-coding-agents", "canonical_source": "https://www.oconeeruntime.com/news/policy-enforcement-for-browser-ai-and-coding-agents", "published_at": "2026-09-03 12:03:57+00:00", "updated_at": "2026-09-03 12:24:31.749390+00:00", "lang": "en", "topics": ["ai-safety", "ai-agents", "ai-policy", "developer-tools"], "entities": ["Oconee Runtime", "Henry Thomas", "OWASP"], "alternates": {"html": "https://wpnews.pro/news/show-hn-oconee-runtime-policy-enforcement-for-browser-ai-and-coding-agents", "markdown": "https://wpnews.pro/news/show-hn-oconee-runtime-policy-enforcement-for-browser-ai-and-coding-agents.md", "text": "https://wpnews.pro/news/show-hn-oconee-runtime-policy-enforcement-for-browser-ai-and-coding-agents.txt", "jsonld": "https://wpnews.pro/news/show-hn-oconee-runtime-policy-enforcement-for-browser-ai-and-coding-agents.jsonld"}}