3LS Platform

One platform for AI inventory, policy and response.

3LS connects observed AI and MCP resources with signed policies, approvals, findings and remediation evidence. Security teams operate controls, governance teams review decisions, and service owners respond to issues from one console.

Product
3LS Platform
Operating surface
Management console and service
Control points
Supported browser, API gateway and managed MCP integration points

Different tasks. One operating surface.

Security operator

Review observed resources, configure supported controls and follow a finding through its policy decision and response.

Governance reviewer

Review signed policy versions, approvals and available records against the organisation’s governance questions.

Service owner

Own the response to an assigned issue, record the action taken and retain remediation evidence.

What runs where

The management console and service connect operator work with signed policy and records. The gateway and supported endpoint, browser and MCP integrations apply configured controls and report the evidence available on their paths.

Platform components and supported flows

Conceptual deployment diagram. Policy distribution and evidence reporting are separate from the paths that carry governed requests.

Management console

Operators manage policy, review inventory and respond to findings.

Operator workflow

Management service

Signed policies, inventory, approvals, case history and bounded evidence.

↓ Policy and configuration to supported components

↑ Evidence to review in the management service

3LS Gateway

Prompt classification, model routing, usage controls and configured tool-proposal checks.

Endpoint / Browser integration

Observed resources and supported site controls for selected text and upload metadata.

Managed MCP integration

Original argument checks, supported approvals and returned-result inspection.

Governed request paths

Solid arrows below show requests on supported configured routes.

  1. Client / agent harness
  2. 3LS Gateway
  3. Approved, eligible model provider
  1. MCP client
  2. Managed MCP argument gate
  3. Tool backend

The gateway can also inspect model-generated tool proposals before delivery to the harness on configured protected response paths. Browser controls apply at the supported site interaction. Direct provider or backend access requires separate controls.

Five capabilities across the platform

AI and MCP Inventory

Discover observed AI products, provider accounts, MCP installations and tool revisions. Track ownership, provenance and observation freshness.

AI Gateway Controls

Use prompt classification, model routing, cost control and tool security before harness delivery on configured gateway paths. Select among approved, eligible models and inspect selected fields.

  • Prompt classification
  • Model routing
  • Cost control
  • Tool security before harness delivery
Explore the AI Gateway →

Policy and Approvals

Validate and publish signed policies, track their application, and manage case-linked exceptions with defined scope, approval and expiry.

Risk and Response

Prioritise findings, assign case owners and retain recorded actions and remediation evidence.

Governance Evidence

Review attributable policy decisions, activity and case history. Use tenant-authorised inventory exports to share observed resources for governance reviews.

See all product capabilities →

Illustrative composite · sample data

Follow the decision into operator response

This example brings together inventory, a managed MCP decision and case work. It does not imply every event automatically creates a case or that every record is joined into one history.

  1. 1. Observed resource

    A sample workstation has a user-configured postgres-mcp installation. Inventory records its association, provenance and observation freshness.

  2. 2. Applicable policy

    Illustrative engineering-mcp-v7 policy permits read operations and requires approval for a delete action on this supported managed path.

  3. 3. Decision

    The delete action is held before backend dispatch while approval is pending. The decision retains its policy and action class; the backend has not been called.

  4. 4. Case owner

    A sample responder reviews a related finding and records the response in an assigned case.

  5. 5. Remediation evidence

    The responder records withdrawal of the delete request and evidence of the corrected read-only workflow.

Walk through a policy decision →
Illustrative operator evidence view highlights PII in selected prompt text and records a policy evaluation with its rationale.
Separate illustrative selected-text record. This is a policy-evaluation example, not a screenshot of the MCP case above.

Agree the requirements for your environment

Discuss supported clients and channels, inspected fields, identity, policy application, hosting, retention and handoff requirements. Confirm installation and enrollment for the deployment, together with connector compatibility and service terms.

Gateway paths

Configure approved provider accounts, eligible model routes, tool groups and selected fields. Apply request-rate controls and eventual monthly usage thresholds.

Browser interactions

Inspect selected prompt text on supported sites. Conversation-history inspection depends on policy; upload controls use file metadata rather than file contents.

Managed MCP operations

On supported managed MCP stdio paths, original argument checks can precede backend dispatch. Result denial cannot undo an action already executed.

Your organisation owns the controls over reachable tools, credentials, shared state, and delegated authority. Direct provider and backend access requires separate controls.

Compliance and Assurance

Evidence for your governance programme

Use inventory, signed policies, approvals, activity and remediation records to support governance reviews. Combine product records with organisational assessments, policy, competence and supplier diligence.

Map your governance questions to product evidence →

Why we called it Three Laws Security

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.