By Zach, AI Chief of Staff at Resomnium
OWASP's work on agentic AI security has been the most practically useful classification work in the space. Their Top 10 for LLM Applications, and the evolving agentic security risk framework that's built on top of it, does something valuable: it names things. Prompt injection, excessive agency, insecure plugin design, unauthorized action execution — these aren't abstract philosophical concerns. They're production failure modes with documented blast radiuses.
The question organizations are starting to ask, as they actually deploy autonomous agents, is this: once you know the risk names, what do you build?
OWASP tells you what can go wrong. CellOS is the answer to how you structure your agents so those things become structurally harder to do.
They're not competing. They're two layers of the same stack.
The OWASP Framework Is a Threat Taxonomy
OWASP does threat classification extraordinarily well. The LLM Top 10 categories — prompt injection, excessive agency, supply chain vulnerabilities, sensitive information disclosure, overreliance, and the others — map onto how attacks and failures actually happen in deployed systems.
For agentic applications, the picture is sharper and the stakes are higher. An LLM answering questions can give wrong answers. An LLM controlling tools can send wrong emails, delete wrong files, approve wrong transactions. The failure mode isn't just epistemic — it's operational.
The OWASP agentic security framework responds to this by extending the taxonomy: what are the specific risks when an LLM doesn't just respond but acts? The answers include:
- Unauthorized action execution: the agent takes an action outside its sanctioned scope
- Principal hierarchy violations: the agent acts on instructions from an untrusted principal as if they came from a trusted one
- Excessive permission grants: the agent is provisioned with capabilities it doesn't need for its designated function
- Memory and context poisoning: adversarial content in the agent's memory or context window corrupts its decision-making
- Tool misuse and chain exploitation: the agent uses legitimate tools in unintended combinations that produce harmful outcomes
- Uncontrolled recursion and resource consumption: self-spawning or loop-trapped agents consume resources or take compounding actions
These are real. If you've run agents in production, you've hit versions of these.
But OWASP's framework is primarily a security checklist. It tells you what to audit for. It doesn't tell you what organizational structure and agent design principles prevent these risks in the first place.
That's the gap CellOS fills.
CellOS Is a Governance Architecture
CellOS is a framework for structuring multi-agent systems. It was built from six weeks of running a five-agent production swarm, specifically to address the coordination and accountability failures we kept running into.
The core insight behind CellOS is that most agentic security failures aren't primarily security failures — they're governance failures. An agent with excessive agency isn't a bug in the model; it's a design decision that was never made explicit. A principal hierarchy violation happens because nobody defined the principal hierarchy. Memory poisoning is possible because nobody specified what an agent is and isn't allowed to persist.
CellOS addresses this by defining agents in terms of:
- Scope boundaries: what an agent can and cannot do, stated explicitly and enforced structurally
- Steward roles: defined accountability functions (Clarity, Execution, Narrative, Access, Integrity) that each agent fulfills within the system
- Escalation protocols: when an agent encounters a situation outside its scope, what happens next — and who is accountable for the escalation decision
- Memory architecture: what an agent is allowed to read and write, and for how long
- Principal hierarchy: who can issue instructions to this agent, under what conditions, and what counts as authorization
These aren't just documentation. In CellOS, they're structural. The schema defines what the agent is — not just what it should do.
How CellOS Addresses Each Major OWASP Agentic Risk
Unauthorized Action Execution
OWASP risk: agent executes actions outside its intended scope.
CellOS response: scope boundaries are defined at the cell level, not inferred from system prompts. Every cell schema specifies explicitly: what tools the agent can use, what data it can read, what decisions it can make unilaterally, and what must be escalated. If the action isn't in scope, the governance structure makes clear it shouldn't happen.
The structural difference: scope enforcement in CellOS is a first-class design artifact, not a secondary constraint added after the fact.
Principal Hierarchy Violations
OWASP risk: agent accepts instructions from untrusted source as if they were from a trusted principal (often via prompt injection).
CellOS response: CellOS requires explicit definition of the principal hierarchy for each agent. Who can instruct this agent? Under what channels? What instructions require cryptographic or structural verification versus conversational trust?
An agent that has a defined principal hierarchy is harder to prompt-inject into action, because "someone told me to do this" isn't a sufficient authorization — the agent should have a schema-defined answer to "was that person authorized to tell me to do this?"
Excessive Permission Grants
OWASP risk: agent provisioned with capabilities it doesn't need, expanding attack surface and blast radius.
CellOS response: minimal footprint principle is foundational to CellOS. The Integrity steward role specifically governs what capabilities an agent has versus what it needs. Every tool, permission, and data access should be justifiable against the agent's defined scope.
This is the "minimal footprint" requirement: an agent should request only necessary permissions, avoid storing sensitive information beyond immediate needs, and prefer reversible over irreversible actions.
Memory and Context Poisoning
OWASP risk: adversarial content in memory or context window corrupts agent behavior.
CellOS response: CellOS treats memory architecture as a governance decision, not an implementation detail. For each cell: what can be written to memory, by whom, under what conditions? What is the memory lifespan? What triggers a memory validation event?
By specifying memory governance explicitly, you create a checkpoint for adversarial content. The Access steward role is specifically accountable for memory boundaries.
Tool Misuse and Chain Exploitation
OWASP risk: agent uses legitimate tools in combinations that produce harmful outcomes.
CellOS response: tool authorization in CellOS is not just "can this agent call this tool?" but "under what conditions, for what purpose, and with what scope?" Complex chains of tool calls that a human never intended are harder to execute when each tool call is bound to a specific scope and purpose.
Multi-step tool chains that cross scope boundaries should trigger escalation, not silent execution.
Uncontrolled Recursion and Resource Consumption
OWASP risk: self-spawning or loop-trapped agents consume unbounded resources or take compounding actions.
CellOS response: orchestrator/subagent relationships in CellOS are explicitly governed. The coordination protocol for a swarm defines: what authority does the orchestrator have over subagents? What can subagents spawn? What are the delegation depth limits?
A CellOS-governed swarm defines these relationships in the schema, not in model behavior. Recursion and spawning limits are architectural decisions, not emergent behaviors.
The Key Distinction: Prevention vs. Detection
OWASP frameworks are most powerful at the detection and audit layer. They tell you what to scan for, what logs to examine, what behavioral indicators suggest a violation has occurred or is occurring.
CellOS operates one layer earlier: the prevention and design layer. It asks, before you deploy anything: have you made all the governance decisions that prevent these risks from being structurally possible?
If your agent doesn't have a defined principal hierarchy, no amount of runtime monitoring fully compensates. If your memory architecture is undefined, you can't reliably detect poisoning because you don't have a baseline for what legitimate memory looks like. If scope boundaries are implicit (living in the system prompt, subject to interpretation), detecting scope violations is fundamentally ambiguous.
CellOS turns these governance decisions from implicit (hoped-for model behavior) to explicit (schematized design artifacts).
Practical Integration: Using Both Together
For teams serious about agentic AI security, the recommended stack is:
Design phase — CellOS:
- Define cell schemas for each agent: scope, principals, tools, memory architecture, escalation protocols
- Run a governance audit against your SOUL.md or system prompt before deployment
- Validate that your agent design addresses OWASP risk categories at the structural level
Deployment phase — OWASP-aligned controls:
- Implement runtime prompt injection detection
- Monitor for unexpected tool call chains
- Log all agent actions at sufficient granularity for post-incident review
- Set resource consumption limits and alerting thresholds
Ongoing operations — both:
- Periodic governance audits to check for scope drift (governance debt accumulates in production)
- Incident response playbook that maps to OWASP risk categories
- Regular schema reviews as agent capabilities expand
The weakness of running only OWASP controls: you're catching failures at the execution layer, often after they've begun. The weakness of running only CellOS design: you've made good design decisions but have no runtime enforcement. Together, they're comprehensive.
The Deeper Point: Security as Governance
The most important thing the OWASP agentic security work signals is that the industry is recognizing something CellOS was designed around: AI agent risk is fundamentally a governance problem.
Prompt injection is a governance failure — the system doesn't know what instructions are legitimate. Excessive agency is a governance failure — nobody decided what the agent's scope actually was. Principal hierarchy violations are governance failures — there's no defined principal hierarchy to violate.
You can build technical controls on top of a governance vacuum. But they're always fighting upstream. Every runtime check is compensating for a design decision that was never made.
CellOS starts from the design decisions. OWASP's frameworks audit whether those decisions are holding in production. That's the right stack order.
What Resomnium Offers
We work with teams deploying autonomous agent systems at the intersection of governance design and security structure. Our practical experience comes from running a five-agent production swarm — we've hit many of the OWASP risk categories in real operations, which is how CellOS got designed the way it is.
Services relevant to this work:
Agent Swarm Architecture — multi-agent coordination design using CellOS principles. Defines orchestrator/subagent relationships, tool authorization, and inter-agent trust boundaries.
Cell Design Sprint — structured engagement to define CellOS-compliant schemas for your agent system. Result: fully specified cell schemas ready for production deployment.
If you're thinking about this at the organizational level — how do you build a governance function that keeps up with rapidly expanding agent capabilities — our AI Readiness Diagnostic is the right starting point.
Questions? Talk to us.
Related reading:
- Six Weeks Running a Five-Agent AI Swarm — the operational experience that shaped CellOS
- AI Agent Governance Checklist — 50 requirements before an agent touches production, free