
Why We Called It Three Laws Security
Chris Inglis compared an autonomous AI to a dog told to hunt rabbits beside an open gate. The instruction is only part of the system. Someone still has to control the gate.
Runtime control layer
3LS gives your organisation visibility across Codex, Claude, browsers, and MCP-connected systems, with discovery, classification, policy evaluation, and evidence for broad AI use. Your organisation owns the controls over reachable tools, credentials, shared state, and delegated authority. On supported managed MCP stdio paths, 3LS can grant or deny before downstream and record journalled outcomes.
Why Three Laws?
Asimov described an order of responsibility. He did not describe a security architecture. We use the name because the organisation, not the model, must decide what its agents are allowed to do.
Broad AI activity can be discovered, classified and evaluated. Pre-execution grant or deny remains limited to supported managed MCP stdio paths.
A small set of runtime decisions security teams can explain, audit, and apply consistently.
See how people, assistants, and agentic tools are using AI across the organization.
Understand whether AI is being used for drafting, coding, research, data handling, or higher-risk workflows.
Detect PII, secrets, and restricted content before it becomes an incident or a compliance problem.
Evaluate observed activity against policy. Supported managed MCP stdio operations can be granted or denied before downstream.
Go deeper into fleet inventory, managed MCP actions, risk and cases, policy rollout, approvals, privacy-safe evidence, and enterprise integrations.
See all product capabilitiesDiscover unmanaged AI use across browsers, assistants, coding tools, and agentic workflows before it becomes an exposure problem.
Identify usage across tools like Codex, Claude, browser-based assistants, MCP-connected workflows, and other agentic tools.
Understand which tools and workflows align with policy and which ones need review, coaching, or controls.
Track adoption, risky behavior, and sensitive usage patterns so security teams can act early.
Focus operator attention on the usage, content, and actions that actually change risk.
Classify whether AI is being used for drafting, coding, research, summarization, or sensitive data handling.
Highlight when prompts, outputs, or tool actions involve PII, credentials, or restricted internal data.
Apply policy based on context, from simple visibility and evidence to review and escalation.
Give security teams clear evidence and effective controls without turning every AI interaction into a manual review queue.
See usage patterns clearly.
Understand which tools are managed and which are shadow AI.
Respond to risky behavior with consistent controls.
Keep a clear audit trail of findings and outcomes.
Detect shadow AI usage, understand how tools like Codex and Claude are being used, and evaluate that activity against policy with clear evidence.
From the blog
Research that explains the platform problem space: shadow AI, enterprise context, tool risk, and the visibility required before controls can work.

Chris Inglis compared an autonomous AI to a dog told to hunt rabbits beside an open gate. The instruction is only part of the system. Someone still has to control the gate.

OpenAI rebuilt the service, but the agents recreated their shared channel. The incident shows why enterprises must control persistent state, credentials, communication paths, and delegated authority themselves.

An AI vendor can secure its product, but it cannot see your copied data, approvals, internal policy, or tool entitlements. The enterprise still owns AI context security.