AOSIQ is a capability-authorization runtime for AI agents — with built-in human approval gates, tamper-evident audit, and per-class data-egress envelopes. The same governance primitives extend to deterministic actors: scheduled jobs, monitoring scripts, and automation pipelines that need the same scrutiny but don't need to reason.
Industry data from 2025–2026 documents an authorization gap that has widened as agent deployment has outpaced governance maturity. The numbers below come from independent Cloud Security Alliance studies — methodology disclosed, sample sizes published, CSA's research arm conducting the analysis. They focus on AI agents, but the gap they describe is part of a longer pattern: enterprise automation governance has been an unsolved problem for years, and AI agents are the version where it's finally undeniable.
Two standards bodies have now formalized the framing. NIST IR 8596 (preliminary draft, December 2025) is the first U.S. government cybersecurity framework profile explicitly addressing AI systems, including autonomous agents that act without direct human intervention. OWASP Top 10 for Agentic Applications 2026 (peer-reviewed framework, December 2025) names identity and privilege abuse and insecure inter-agent communication among the ten highest-impact risks for autonomous AI systems. AOSIQ implements the runtime invariants these standards describe.
AOSIQ enforces governance properties as runtime invariants — not best practices, not configuration, not policy documents. Every operation crosses a single syscall boundary where capability, audit, approval, and cost checks fire before the action ever reaches the underlying system.
Every actor — reasoning agent, scheduled job, automation script — carries a signed JWT capability token listing exactly which tools it may invoke. Child actors receive the intersection of the parent's grants and the child's request — never more. Verification fires before every tool call. There is no ambient authority.
Tools registered as reversible=False trigger a checkpoint
and a human review row. Approvals are bound to a specific
(tool, args_hash) pair and are single-use. Repeat calls
require fresh approvals. The blast radius is visible at the moment
of decision.
Spawn, tool call, memory write, state transition, capability denial, approval — each becomes one row, each cryptographically chained to the last. Anchor objects in independently-credentialed object storage make mid-chain tampering detectable even by an attacker with PostgreSQL write access.
Every LLM call records model, tokens, and computed USD cost. Deterministic actors record their compute consumption in the same ledger. Configurable session ceilings fire as exceptions, not invoices. Costs roll up by actor class, by session, by day. Per-class data-egress envelopes let an actor class be forbidden from routing to specific providers regardless of operator configuration.
The runtime borrows operating-system shape deliberately: actors are processes, the syscall interface is the kernel API, capability tokens are the security context, the audit log is the system log. A single enforcement boundary funnels every operation through the same checks — regardless of whether the actor is a reasoning agent or a deterministic script.
┌────────────────────────────────────────┐
│ HTTP layer (FastAPI · MCP · dashboard)│
└──────────────────┬─────────────────────┘
│
┌──────────────────▼─────────────────────┐
│ AOSSyscall ── single policy boundary │
│ • capability verification │
│ • approval gate (irreversible) │
│ • audit chain append │
│ • cost ledger record │
│ • memory operations │
│ • tool dispatch │
└──┬─────────────────┬─────────────────┬─┘
│ │ │
┌──▼────────┐ ┌─────▼────────┐ ┌─────▼─────┐
│ Kernel │ │ Memory │ │ Tool │
│ scheduler │ │ working │ │ native │
│ recovery │ │ semantic │ │ MCP │
│ ACB │ │ episodic │ │ KB │
│ registry │ │ experiential │ │ sandbox │
└───────────┘ └──────────────┘ └───────────┘
AOSSyscall
where governance fires uniformly.
The agent-OS landscape has converged on a 13-layer vocabulary (Experience → Intent → Planning → Agent → Runtime → Memory → Tool → Integration → Governance → Observability → Intelligence → Data → Infrastructure, plus cross-cutting Event / Identity / Capability / Economy systems). AOSIQ adopts the vocabulary with one addition — a 14th layer, Composition, slotted between Agent and Runtime — and with an honest scorecard of where each layer actually stands today.
Strong (~80%+): Runtime, Tool, Governance, Observability. Real but partial (~60–75%): Composition, Memory, Intelligence, Data. Defined but early (~40–50%): Agent, Integration, Experience, Infrastructure. Positioning only (<30%): Planning, Intent — these layer names appear in the vocabulary but the surfaces are deliberately not built. Planning at ~30% is a feature, not a bug: regulated-infra customers buy operator-authored YAML workflows, not LLM-generated plans.
Architecture quality = execution continuity, not abstraction count. The Composition Layer is named to keep that discipline visible. Full scorecard + rationale: docs/architecture.md · ADR-006
The customer profile is anyone running actors — AI agents, scheduled jobs, automation scripts, or any combination — that take real actions on real systems where unsupervised destructive operations are unacceptable. Four shapes recur.
Production systems where state changes need sign-off and audit. Read-only diagnostic agents, scheduled monitoring jobs, automated remediation pipelines — all governed uniformly. IBM i shops, Kubernetes operators, database administrators, network engineers, security incident responders. The pattern: actors triage, propose, and surface evidence; humans authorize every keystroke that mutates state.
Financial services, healthcare, legal, insurance, utilities. The environments where "we used AI" is acceptable only if "here is the cryptographic record of every action it took, who authorized state changes, and how much each session cost" comes with it.
Teams running concurrent reasoning agents alongside deterministic jobs, where coordination, capability boundaries, and cost attribution matter at the per-session level. Same governance primitives for every actor, no separate audit story for AI versus automation. AOSIQ provides the substrate; the application provides the actors.
Claude Code and similar IDE-integrated agents that spawn sub-agents for code review, bug investigation, or release readiness — workflows where the parent session shouldn't grant the child everything it has. AOSIQ ships an MCP server for one-config-change integration.
The earliest engagements are with a small group of design partners in regulated infrastructure. If your operation runs AI agents against production systems and the governance gap is keeping you up at night — that's the conversation we want to have.
Tell us a little about what you're working on. We respond within two business days, and the first conversation is consultative — we'll tell you honestly whether AOSIQ is the right fit before discussing anything else.