> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sector8.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Red teaming

> Test the live Sector8 contract: routed action, expected decision, evidence fields, and fail-closed behavior.

Sector8 red teams the execution boundary itself: whether a routed agent action receives the expected `ALLOW` or `DENY` decision before side effects start, plus review behavior on review-enabled guard paths.

<Info>
  Every AI security tool tests what your model says. Sector8 tests what your agents can do on paths routed through the gate.
</Info>

## The challenge

<CardGroup cols={3}>
  <Card title="Models change. Agents act." icon="bot">
    A prompt-only assessment does not tell you what happens when an agent can read files, call tools, hit APIs, or operate across business systems.
  </Card>

  <Card title="Agents expand the blast radius" icon="shield-alert">
    Once an agent has tool access, the real risk is data access, cross-scope reads, shell misuse, SSRF, and policy bypass on ungoverned paths.
  </Card>

  <Card title="Most tools stop too early" icon="triangle-alert">
    They test prompts and responses. They do not test the evaluate-before-dispatch contract where business risk actually happens.
  </Card>
</CardGroup>

## Sector8's approach

Red team the real integration contract:

1. Route a proposed action through Sector8
2. Expect a specific decision (`ALLOW` or `DENY`) or a review pause on review-enabled guard paths
3. Confirm evidence fields are present
4. Confirm the runtime honors the decision and fails closed on unknown/error

What that means in practice:

* test real tool, SDK, REST evaluate, and MCP-connected paths
* test authorization and ownership failures
* test whether a routed agent can exfiltrate data, cross tenant boundaries, hit private infrastructure, or violate policy before execution
* confirm unconnected paths are treated as out of coverage, not assumed protected

<Tip>
  The goal is not only to prove that a model can say something risky. The goal is to prove whether a routed agent action is decided and honored correctly before execution.
</Tip>

## How red teaming works

<Steps>
  <Step title="Exercise real agent workflows">
    Test tool use, file access, web access, shell actions, MCP servers, and cross-system agent behavior on the paths you actually route through Sector8.
  </Step>

  <Step title="Target the evaluate boundary">
    Probe the decision point that determines whether the agent may act, not only what the model says.
  </Step>

  <Step title="Assert the contract">
    For each case, record:

    | Check             | Pass condition                                                                                   |
    | ----------------- | ------------------------------------------------------------------------------------------------ |
    | Routed action     | Proposed action went through evaluate or the Sector8 connector                                   |
    | Expected decision | `ALLOW` or `DENY` matched the case design; review-enabled paths paused when expected             |
    | Evidence fields   | `reason_code`, `decision_trace_id`, `evidence_hash`, and `policy_version_id` present as expected |
    | Runtime honor     | App dispatched only on `ALLOW`; blocked on `DENY`; review-enabled paths paused when expected     |
    | Fail-closed       | Missing, unknown, error, or timeout did not execute                                              |
  </Step>

  <Step title="Feed runtime protection">
    Turn findings into deny reasons, review policies, alert signatures, traces, and enforcement improvements.
  </Step>
</Steps>

## What Sector8 tests

| Area                    | What gets tested                                                                                           |
| ----------------------- | ---------------------------------------------------------------------------------------------------------- |
| Tool execution          | whether the agent can invoke the wrong tool or invoke the right tool in the wrong context on a routed path |
| Ownership and scope     | cross-tenant reads, BOLA, BFLA, and unauthorized object access                                             |
| Request risk            | SSRF, private IP access, external-domain misuse, shell injection, obfuscated payloads                      |
| Sensitive data movement | PII, PHI, and policy-protected data before execution                                                       |
| MCP and agent workflows | whether real multi-step agent paths create unsafe action sequences                                         |
| Fail-closed behavior    | whether evaluate unavailability or unknown decisions prevent dispatch                                      |

## Why this is different

<CardGroup cols={2}>
  <Card title="Most AI security tools" icon="message-square">
    Test prompts and outputs, then report what the model said or might have said.
  </Card>

  <Card title="Sector8" icon="shield-check">
    Tests whether the routed execution boundary returns the expected decision and whether the runtime honors it before side effects start.
  </Card>
</CardGroup>

## Stronger together

Sector8 red teaming is not a separate reporting surface. It validates the live gate contract.

* red teaming validates whether dangerous routed actions are denied or sent to review before execution
* runtime protection improves as findings become deny paths, review rules, and policy updates
* telemetry and framework mappings stay grounded in what was actually exploitable on governed paths

See related guides:

* [Guardrails](/guides/guardrails)
* [Evaluate](/api-reference/evaluate)
* [Compliance overview](/guides/compliance)
* [EU AI Act](/guides/eu-ai-act)

<Check>
  Red teaming is complete when you can show a routed action, the expected decision, the evidence fields, runtime honor behavior, and fail-closed handling -- not only that a prompt looked risky.
</Check>