# Sector8 — full marketing copy (markdown) Source: content/pages in the sector8-website repo. No JavaScript required. --- path: / status: canonical title: Sector8 — AI agents are approving their own actions. The model proposes. The gate authorises. description: >- Before AI accesses customer data, issues a refund, updates a system, or calls a connected tool, Sector8 returns ALLOW or DENY with a reason code and evidence record. Start with a shadow-mode pilot. primary_cta: { label: Request a shadow-mode pilot, href: /contact } secondary_cta: { label: How shadow mode works, href: /shadow-mode } --- # AI agents are approving their own actions. The model proposes. The gate authorises. Before AI accesses customer data, issues a refund, updates a system, exports records, changes a file, or calls a connected tool, Sector8 returns ALLOW or DENY. The agent does not approve itself. Same gate for coding agents, internal copilots, and customer-facing tools. See `/product`. Sample evaluate artifact. Field names match the evaluate contract. Not a named customer. Developer `.env` is the proof, not the only story. ``` { "tool_name": "Bash", "arguments": { "command": "cat .env" }, "caller_id": "claude-code", "session_id": "eng-session-07", "operation": "read" } ``` Decision: DENY. `reason_code` `SENSITIVE_PATH_BLOCKED`. `decision_trace_id` `17e797c0-eb5c-4f97-b4a1-2d3e4f5a6b7c`. `evidence_hash` `4cb7f786d1f3b57e6f98f3e60d2eb6b8`. `policy_version_id` `pset_default`. ## The gap Your agents are proposing and approving in the same breath. An agent decides it needs to read a file, run a command, call a tool, or move money. Then it does it. The thing that decided is the thing that authorised. No other system in your estate works that way. Three consequences you already recognise: - **The agent has your permissions, not its own.** It runs with a service account scoped for a human doing a whole job, not for one action. Every tool it can reach, it can use. - **An injected instruction becomes a real action.** You cannot reliably detect a prompt injection — that is a classifier, and classifiers are probabilistic. But an injected instruction still has to become a tool call before it does damage. That is the point where it can be refused rather than detected. - **You find out from the logs.** The refund is issued. The export has left. The deploy is live. Detection tells you what happened; it does not decide whether it should have run. And the part most teams cannot answer: what have your agents already tried? Not what they were allowed to do — what they attempted, in the last two weeks, that nobody saw. ## What your agents already tried Two weeks. Enforcement off. Nothing is blocked. Sector8 still evaluates every proposed action and records what it would have returned: ALLOW or DENY. You leave with a finding, then you choose which controls to turn on. Sample decision tape, not a customer report. Most rows would have been allowed. The denials use public codes. | Time | Agent | Action | Decision | Reason code | |---|---|---|---|---| | 00:02 | support-assistant / crm | API · CRM lookup | ALLOW | | | 00:08 | finance-copilot / ap | API · invoice status | ALLOW | | | 00:14 | claude-code / checkout-svc | Bash · echo hello | ALLOW | | | 00:19 | internal-copilot / hr | API · own leave record | ALLOW | | | 00:24 | support-agent / billing | API · customer record | DENY | BOLA_VIOLATION | | 00:31 | claude-code / checkout-svc | Bash · cat .env | DENY | SENSITIVE_PATH_BLOCKED | ## After the fact is too late | Enforcement point | Timing | What is already exposed | |---|---|---| | Sector8 gate | Before the proposed action executes | None from that action. The side effect has not started. | | Output filters / model safety | After the model generates content | The model may already have seen sensitive input. | | SIEM / DLP | After network or tool activity | Data or action may already have moved. | | Audit logs alone | After execution | Detective only. | ## Propose. Decide. Prove. 1. **Propose.** The agent emits a tool call. 2. **Decide.** ALLOW or DENY before execution. If the gate cannot allow the action safely, it denies. 3. **Prove.** Reason code, decision trace ID, evidence hash, policy version. We do not try to govern what the model thinks. We govern what it is allowed to do. ## A control you can test Fire the same attack at the same policy a thousand times and you get the same DENY a thousand times. If it is not reproducible, it is not a control. ## Questions before a pilot Classification can be one check. The control is the admission decision — ALLOW or DENY. Not a GDPR certificate. **How is this different from filters or gateways?** Filters act on text. Gateways act on which tools exist. Sector8 decides whether a specific proposed action may execute, before the side effect starts. **What about high-risk or uncertain actions?** REST evaluate returns ALLOW or DENY. If the action cannot be allowed safely, it is denied. On the MCP connector path, a borderline action can be held for a human; if nobody answers, it is denied. --- --- path: /product status: canonical title: Sector8 Product — The Runtime Gate for AI Agents description: >- Sector8 is the control point between AI systems and the business actions they want to take. Before AI accesses data, issues a refund, updates a system, or calls a connected tool, Sector8 returns ALLOW or DENY. primary_cta: { label: Request a shadow-mode pilot, href: /contact } secondary_cta: { label: How shadow mode works, href: /shadow-mode } --- # The Sector8 Gate Sector8 is the control point between AI systems and the business actions they want to take. Before AI accesses data, issues a refund, updates a system, exports records, changes files, or calls connected tools, Sector8 returns ALLOW or DENY. The agent does not approve itself. For technical teams, that means policy-based control over API calls, file operations, shell commands, MCP tools, deployments, and connected systems. Same action. Same policy. Same decision. Every decision creates a record of what was checked and why. Business-action surfaces: refunds, exports, customer data, system updates, workflow actions. Technical surfaces: shell, filesystem, network, MCP, CI/CD. ## Propose. Decide. Prove. 1. **Propose.** The AI system proposes an action. Your runtime sends that proposed action to Sector8 before it happens. This can include tool calls, API calls, model calls, file operations, handoffs, or workflow actions. 2. **Decide.** A deterministic policy engine returns ALLOW or DENY. If it cannot allow the action safely, it denies. No model judges another model. 3. **Prove.** Reason code, decision trace ID, evidence hash, policy version. Allows are recorded, not just denials. We do not try to govern what the model thinks. We govern what it is allowed to do. ## Connect Sector8 before AI reaches your systems Choose the integration path that fits your AI workflow. Start in shadow mode, record decisions, then turn on enforcement when ready. Sector8 is model-agnostic. It works wherever proposed actions can be routed through the gate: APIs, SDKs, agent runtimes, MCP tools, internal copilots, and customer-facing workflows. The control boundary is AI-to-action, not application-to-model. - REST: `POST /api/v1/evaluate` from any runtime. - Python SDK: `sector8-sdk`. - TypeScript SDK: `@sector8/sdk`. - Claude Code / MCP: route governed tool calls through the Sector8 connector. REST evaluate returns ALLOW or DENY. On the MCP connector path, a borderline action can be held for a human; if nobody answers, it is denied. - Business workflow / API: route proposed business actions such as refunds, exports, CRM updates, and account changes through the same evaluate contract. Set a client timeout of at least ten seconds so a slow or failed call fails closed instead of executing — that timeout is a safety backstop, not an expected latency. If the gate cannot decide, the action does not run. Enterprise controls included: tenant-isolated policy enforcement; EU-hosted deployment; encryption in transit and at rest; versioned policy sets, bound per tenant; auditable decision evidence. ## Where it matters - Customer-facing agents: refunds, exports, account changes, CRM updates, customer record access, and other actions that move money or data. - Internal copilots: HR, finance, legal, operational, customer, and knowledge systems before AI acts on sensitive information. - Coding agents: shell commands, file changes, repository access, deploys, secrets, MCP tools, and CI/CD workflows before they run. Public reason codes live on `/reason-codes`. Branch on the decision, not on a specific code. ## Shadow mode first 1. Identify the action surface. 2. Route proposed actions (SDK, REST, or Claude Code connector). Only routed tools are governed. 3. Run shadow mode. Enforcement off. ALLOW and DENY are still recorded. 4. Turn on selected policies after the report. Product UI is shown with enforcement enabled. Shadow mode records the same decisions without blocking. Example flow: a proposed action is routed through Sector8, evaluated against policy, denied before execution, and recorded with audit evidence. ## Where Sector8 fits Sector8 is not a replacement for SIEM, DLP, content security, or governance programmes. Sector8 supports evidence collection, but does not certify GDPR, HIPAA, or EU AI Act compliance by itself. Sector8 governs actions routed through the gate. Shadow mode helps identify coverage gaps. Classification can inform a decision, but the control point is whether the proposed action is admitted. --- --- path: /shadow-mode status: canonical title: Sector8 Shadow Mode — Test AI Agent Enforcement Without Blocking description: >- Run Sector8 in shadow mode to evaluate AI agent actions, log what would have been denied, and receive a policy gap report before turning enforcement on. primary_cta: { label: Request a shadow-mode pilot, href: /contact } --- # Test the gate before you enforce Shadow mode lets you deploy Sector8 alongside existing agents without blocking any actions. Sector8 evaluates each proposed action, records ALLOW or DENY, and shows what would have happened if enforcement were active. Coverage is only for actions your runtime sends to the gate — the pilot is also how you find what is still unrouted. ## How shadow mode works 1. Connect your agent or workflow 2. Route proposed actions to Sector8 3. Keep enforcement off 4. Collect two weeks of decision evidence 5. Review the policy gap report 6. Turn on enforcement for selected rules ## What you get - Would-have ALLOW and DENY outcomes - Reason codes for each decision - Evidence hashes and trace IDs - Policy version references - Agent and tool breakdown, including what never reached the gate - Suggested enforcement priorities --- --- path: /reason-codes status: canonical title: Sector8 Reason Codes — What the Gate Denies and Why description: >- A technical reference for Sector8 denial reason codes the gate actually emits, including what each failure means and how the decision is recorded. --- # Reason-code reference Every DENY includes a reason code, decision trace ID, evidence hash, and policy version. Codes on this page are names the gate emits. Machine copy: `/reason-codes.json`. Branch on the decision, not on a specific code. ## `SENSITIVE_PATH_BLOCKED` Sensitive path access blocked. The agent attempted to read, write, or execute against a protected file path. Example: a developer agent attempts to write to `/etc/secrets.env`, `.env`, private key files, production configuration, or restricted system paths. Evidence: Agent ID, User ID, File path, Action, Environment, Policy version, Decision trace ID, Evidence hash. ## `BOLA_VIOLATION` Broken object-level authorisation. The agent attempted to access or modify an object outside the caller's authorised scope. Example: a support agent tries to read or update a customer record belonging to another tenant, account, or ownership boundary. Evidence: Agent ID, User ID, Object ID, Tenant or ownership scope, Tool name, Policy version, Decision trace ID, Evidence hash. ## `BFLA_VIOLATION` Broken function-level authorisation. The agent attempted to use a function or tool outside its permitted role or capability. Example: an HR assistant attempts to export payroll data or a support agent attempts to invoke an admin-only CRM update function. Evidence: Agent ID, Role, Tool/function name, Requested action, Policy version, Decision trace ID, Evidence hash. ## `TOOL_NOT_REGISTERED` Tool not registered. The agent attempted to invoke a tool that is not registered for that agent or policy. Example: a coding agent calls `apply_terraform` or an MCP tool that was never registered. Evidence: Tool name, Caller ID, Policy version, Decision trace ID, Evidence hash. ## `RATE_LIMIT_EXCEEDED` Rate limit exceeded. The agent exceeded the allowed rate of proposed actions. Example: an agent fires a burst of tool calls above the admission rate limit. Evidence: Tool name, Caller ID, Policy version, Decision trace ID, Evidence hash. ## `GUARD_INTERNAL_ERROR` Gate could not evaluate. Sector8 could not complete evaluation safely. Fail-closed. The action does not run. Example: an unhandled error on the evaluate path. The runtime must not execute. Evidence: Reason code, Decision trace ID, Evidence hash, Policy version. ## `MCP_SHELL_INJECTION_BLOCKED` Shell injection blocked. The proposed command contained a shell-injection pattern. Example: a bash tool call includes command chaining or an injected fragment in the command string. Evidence: Tool name, Decision trace ID, Evidence hash, Policy version. ## `PARAM_INJECTION_DETECTED` Parameter injection detected. Tool arguments contained an injection pattern. Example: a tool argument includes an injected instruction or encoded payload aimed at changing behaviour. Evidence: Tool name, Decision trace ID, Evidence hash, Policy version. ## `PRIVATE_IP_BLOCKED` Private IP blocked. The agent attempted a network call to a private or link-local address. Example: a fetch or HTTP tool targets `127.0.0.1`, `10.0.0.0/8`, or a link-local address. Evidence: Tool name, Decision trace ID, Evidence hash, Policy version. ## `EXTERNAL_DOMAIN_BLOCKED` External domain blocked. The agent attempted a network call to a domain that is not allowed. Example: a tool posts data to an unapproved external host. Evidence: Tool name, Decision trace ID, Evidence hash, Policy version. --- --- path: /security status: canonical title: Security Philosophy — Sector8 description: >- Sector8's security philosophy is pre-execution control: an independent gate decides ALLOW or DENY before an agent action runs. Deterministic, fail-closed, with an evidence record. --- # Decide before the side effect starts. Security here is not a dashboard of what the model said. It is an independent decision on what the agent is allowed to do, before execution. ## How we think about control - Independent gate. The agent does not approve itself. - Before execution. Logs after the fact are not a control. - Deterministic. Same action, same policy, same decision. - Fail-closed for actions your app sends to Sector8. - Evidence: reason code, decision trace ID, evidence hash, policy version. ## What this is not Not LLM observability. Not toxic-output classification. Not a model judging a model. Not a GDPR / HIPAA / EU AI Act certificate. Not a replacement for SIEM, DLP, or customer governance. ## What we receive The proposed action you send. A decision and an evidence record come back. That is not a prompt archive. ## How we run Sector8 - Tenant-isolated policy enforcement - EU-hosted deployment - Encryption in transit and at rest - Versioned policy sets, bound per tenant - Auditable decision evidence Security questionnaires: hello@sector8.ai. --- --- path: /about status: canonical title: About Sector8 — The model proposes. The gate authorises. description: >- Sector8 exists because an agent cannot approve itself. The company builds a deterministic pre-execution gate: propose, decide, prove. Shadow mode first. Fail-closed at the gate. --- # An agent cannot approve itself. Sector8 places an independent decision gate between agents and real-world actions. The model proposes. The gate authorises. ## Founders Kammil Mahajan and Liban Mohamud. UCD MSc Digital Investigation and Forensic Computing, 2011–2013. They reconnected around a concrete gap: organisations were putting agents into production that could approve their own actions. ## Our mission The name is the company. The product is the gate. We do not try to govern what the model thinks. We govern what it is allowed to do. 1. **Propose.** The agent emits a tool call. Before execution, Sector8 receives the proposed action. 2. **Decide.** ALLOW or DENY. If the gate cannot allow the action safely, it denies. The agent does not approve itself. 3. **Prove.** Reason code, decision trace ID, evidence hash, policy version. ## What we stand for Actions, not answers. Determinism. Evidence. Shadow mode first. Fail-closed for actions your app sends to Sector8. --- --- path: /zero-trust-ai-agents status: canonical title: Zero Trust for AI Agents | Sector8 description: >- Sector8 is the execution-governance layer for agentic AI. Verify every governed action before it reaches a tool, API, model, database, or file system. --- # Verify before agents act. Same Gate product as `/product`. Models generate possibilities. Sector8 decides whether a proposed action may execute. The agent does not approve itself. ## What Zero Trust means here - **Verify every action.** Evaluate each governed tool, API, model, database, and file-system action before execution. - **Least agency.** Restrict agents to registered tools and scoped policy. Every tool it can reach, it can use — unless the gate is on the path. - **Produce evidence.** Every decision carries a reason code, decision trace ID, evidence hash, and policy version. ALLOW or DENY. Fail-closed for actions your runtime sends to Sector8. Public reason codes: `/reason-codes`. Branch on the decision, not on a specific code. ## What this is not Not a prompt filter. Not a model judging a model. Not a GDPR, HIPAA, or EU AI Act certificate. Not a replacement for SIEM, DLP, or customer governance. --- --- path: /contact status: conversion title: Request a Sector8 Shadow-Mode Pilot description: >- Tell us about the AI agents, tools, and workflows you want to evaluate. Run Sector8 in shadow mode to see what would be allowed or denied before enforcement. --- # Request a shadow-mode pilot Tell us about the agents, tools, or workflows you want to evaluate. We will help you run Sector8 in shadow mode so you can see what would be allowed or denied before enforcement is enabled. Need product help? Documentation: https://sector8.mintlify.app/guides/introduction Security: hello@sector8.ai Required: Name, work email, company, message. Optional: role, runtime.