Policy as Code (auditors.yaml)
Lucid separates safety logic from infrastructure using a Policy-as-Code approach. You define your security guardrails in a high-level auditors.yaml manifest, and the Lucid CLI/Operator handles the injection.
📄 Manifest Schema
The auditors.yaml file defines a chain of auditors that will be injected into your secured pods.
chain:
- name: string # Unique name for the auditor instance
description: string # (Optional) Description of the auditor's purpose
image: string # The OCI image tag (must be published to Lucid Verifier)
port: integer # The internal port the auditor listens on (e.g., 8081)
env: # (Optional) Environment variables for the sidecar
KEY: VALUE
labels: # (Optional) Custom K8s labels for the sidecar container
key: value
⛓️ How Chaining Works
Auditors are executed sequentially in the order they appear in the chain list.
- Request Flow: Traffic enters the Pod → Auditor 1 → Auditor 2 → ... → AI Model.
- Short-Circuiting: If any auditor returns a
DENYdecision, the request is immediately blocked, and the model is never reached. - Redaction: Auditors can modify (redact) the payload before passing it to the next link in the chain.
💡 Example: Multi-Stage Security
chain:
- name: pii-scanner
image: "lucid/pii-auditor:v1"
port: 8081
description: "Scan for SSN and PII"
- name: injection-detector
image: "lucid/injection-shield:v1"
port: 8082
description: "Prevent prompt injection attacks"
🛠 Usage with CLI
When deploying with the Lucid CLI, you specify the policy file using the --auditors flag:
lucid deploy apply --file my-deployment.yaml --auditors auditors.yaml
The CLI will:
1. Read the definitions.
2. Upload them to the cluster as a ConfigMap.
3. The Lucid Operator will then use this configuration to inject the sidecars during Pod creation.