Product · Guard (Runtime Protection)

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 Lino on the egress path, an eBPF or sidecar agent, and correlation with Griffin's reasoning trace. Included in every tier.

Runtime
Policy enforcement
<10 ms
In-process overhead
Signed
Per-event audit
Every tier
Included

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

Lino 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 Lino on egress and Griffin context on alert — adversarial input and exfiltration patterns are detected in the loop.

How it deploys.

Step 01

Author policy

Same rego-style DSL as CI/admission policy. Version-controlled. Simulation mode before enforcement.

Step 02

Deploy agent

eBPF agent (Linux) or sidecar (K8s / serverless). One-line install. Auto-discovers workloads in scope.

Step 03

Baseline

First 7 days are observation-only. Baseline of normal calls, egress patterns, secret usage.

Step 04

Enforce

Promote to soft enforcement (alert only) for 7 days, then hard enforcement. Anomalies block or alert per policy.

Step 05

Correlate

Runtime events correlated against SBOM + Griffin reasoning traces. Alerts arrive with full context.

Step 06

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

Lino 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.

Same policy. Same audit log. Now at runtime.