GDPR

How Sector8 supports GDPR-oriented controls with pre-execution evaluation and telemetry redaction evidence.

Sector8 can support GDPR workflows at two points in the flow when your runtime routes proposed actions through it:

• before execution, by blocking risky tool calls at the admission boundary
• after execution, by redacting sensitive telemetry before it is stored

Sector8 does not make your organization GDPR-compliant by itself. Use these controls as part of a broader privacy program with legal review.

Where GDPR controls apply

Stage	What Sector8 can do
Pre-execution	Block tool calls that violate configured data-minimisation policy before local dispatch
Post-execution	Apply compliance redaction so prompts and completions can be sanitized before storage
Audit trail	Denied requests carry evidence linkage such as evidence_hash, decision_trace_id, and policy_version_id

Coverage applies to tool calls and telemetry your runtime routes through Sector8. Unconnected paths are not automatically covered.

GDPR controls mapped to shipped behavior

GDPR requirement	How Sector8 can support it
Art. 5 - Data minimisation	Blocks PII-bearing tool calls and unnecessary bulk access before execution with GDPR_DATA_MINIMISATION_VIOLATION when that policy is active
Art. 25 - Privacy by design	Applies policy before the tool runs on the routed path, so protected data is not accessed first and reviewed later
Art. 32 - Security of processing	Uses policy version identifiers, evidence hashes, and fail-closed denial guidance on guard exceptions for the routed path
Art. 33 - Breach response readiness	Blocked telemetry can create incidents and alert events with traceable evidence linkage when those integrations are configured

What gets detected

The GDPR pack is pattern-based. It is designed to catch common high-risk identifiers in tool arguments and telemetry, not to make broad semantic legal judgments.

Examples include:

• email addresses
• phone numbers
• dates of birth
• national identifiers
• financial account patterns

Sector8’s GDPR scoring and enforcement are operational controls, not a certified legal assessment. Use them as guardrails inside a broader privacy program.

What a GDPR denial looks like

When a routed tool call is denied for data minimisation, the public response shape includes:

{
  "decision": "DENY",
  "reason_code": "GDPR_DATA_MINIMISATION_VIOLATION",
  "evidence_hash": "bdbde1558fb883573b0f6e8630ccba1edaf6bed8cb035fa6a48912809149f287",
  "has_forensic_payload": true,
  "decision_trace_id": "32819155-d21a-49c8-9509-79338d980fa9",
  "policy_version_id": "0dbca364d66447469637bafa2282e635124fcb99eecd6383038e3b652577ebc7"
}

Your runtime must honor the decision: execute only on ALLOW, block on DENY, and fail closed on missing, unknown, or failed evaluate results.

How to verify GDPR controls

1. Send a known PII-bearing tool call through POST /api/v1/evaluate.
2. Confirm the response returns DENY with GDPR_DATA_MINIMISATION_VIOLATION and that your runtime does not dispatch.
3. Optionally send a completed interaction through POST /api/v1/telemetry.
4. Confirm stored telemetry is redacted when that path is enabled and evidence linkage is present.

You are done when a risky routed tool call is blocked before execution, your runtime honors the DENY, and corresponding evidence fields are present for audit.