Guard. Runtime protection. Same policy. Same audit log.
Guard enforces the policy you authored for CI and IDE — at runtime. Syscall, library-call, and network-egress level inspection. Powered by Lion on the egress path, an eBPF or sidecar agent, and correlation with Griffin's reasoning trace. Included in every tier.
What Guard does.
Policy enforcement at runtime
The same rego-style policy authored once for CI and IDE is enforced at runtime — syscall, library-call, network-egress level. No drift between gate and runtime.
Guardrails per workload
Per-service guardrails: which sinks may be called, which endpoints may be reached, which secrets may be loaded. Anomalies blocked or alerted based on policy.
eBPF / sidecar instrumentation
eBPF agent on Linux hosts. Sidecar option for serverless or constrained environments. Signed runtime telemetry streamed to your SIEM and the platform's audit log.
Sensitive-data egress block
Lion on the egress path inspects outbound traffic for PII, secrets, and proprietary patterns. Block / redact / alert per policy — at line rate.
Tied into the Griffin pipeline
When a runtime anomaly fires, the platform correlates it against your SBOM and recent reasoning traces. The alert arrives with the call-graph context Griffin already produced.
Customer-controlled response
Block, alert, redact, or pass-through — your call per policy. Break-glass workflow for emergencies. Every decision is signed and audit-logged.
Why runtime protection matters now.
Static analysis can't see runtime drift
Even a perfectly scanned build can be tampered with at runtime — sideloaded libraries, hot-patched functions, in-memory exploits. Guard catches what static analysis cannot reach.
Policy is the contract
The same policy that gates a merge in CI enforces at runtime. No second policy language, no second audit log, no drift between security review and production reality.
Built for the AI era
Modern attacks chain through AI agents and MCP servers. Guard inspects agent tool-call traffic with Lion on egress and Griffin context on alert — adversarial input and exfiltration patterns are detected in the loop.
How it deploys.
Author policy
Same rego-style DSL as CI/admission policy. Version-controlled. Simulation mode before enforcement.
Deploy agent
eBPF agent (Linux) or sidecar (K8s / serverless). One-line install. Auto-discovers workloads in scope.
Baseline
First 7 days are observation-only. Baseline of normal calls, egress patterns, secret usage.
Enforce
Promote to soft enforcement (alert only) for 7 days, then hard enforcement. Anomalies block or alert per policy.
Correlate
Runtime events correlated against SBOM + Griffin reasoning traces. Alerts arrive with full context.
Audit + post-mortem
Every enforcement decision signed and logged. Break-glass bypasses auto-expire and trigger post-incident review.
Use cases Guard unlocks.
Block sensitive-data egress from agentic AI
Lion on the MCP-server egress path catches PII, secrets, and proprietary code in tool outputs before they leave the boundary.
Catch in-memory exploits Griffin couldn't reach statically
Runtime tells you when an actual exploit triggers — even when static analysis missed the path. The reasoning trace + runtime event correlate in one alert.
Enforce admission-controller policy continuously
Pre-deploy gate is necessary but not sufficient. Guard re-checks the runtime workload against the same policy continuously, not just at deploy time.
Stop drift between approved image and running container
If a running container's behaviour diverges from its signed manifest, Guard detects it. Sideloaded libraries, hot-patches, and process injection surface immediately.
Related.
Same policy. Same audit log. Now at runtime.
Guard is included in every tier — bring a workload and we'll show the policy plane running on it.
Self-healing security runs on Safeguard.
Your first fix PR is minutes away.
No sales call required, even your agent can complete the purchase over MCP.