Loading...
Every AgentEvent your instrumentation posts to GreenLightz opens an Evidence Case bounded by six architectural invariants that cannot be toggled off. Security is not a feature — it is the foundation the case rides on.
Every important AI-agent action flows through the same three-object chain. Each object has a stated security boundary and a documented disclosure classification.
Instrumentation posts a JSON body containing action_type, tenant_id, actor_id, target_id, action metadata, and correlation_id. Identifiers are HMAC-hashed with per-tenant keys before storage; 18 known PII field-name aliases across 11 families are rejected at the top of the request payload AND one dict level deeper, plus SSN/PAN/email regex value scanning on payload string values, HTTP 400 with PII_METADATA_BLOCKED before the engine sees the body.
The case answers: what happened, what was required, what was observed, what was missing, who approved it, which policy produced the verdict. Sealed with a deterministic content-hash chain plus the policy_content_hash the verdict was evaluated under.
The sealer emits a canonicalized snapshot containing the AgentEvent, the policy pack hash, the per-rule evaluation records, and the aggregate state. HMAC signing attaches when the operator configures GLZ_PIVOT_V1_HMAC_KEY.
Every evaluation, every tenant, every time. Key governance and claim-boundary properties are covered by automated test suites and release gates; we walk through the exact checks that apply to the deployed scope during technical review.
Any error, timeout, or ambiguity results in BLOCK. The system never silently allows an action it cannot verify.
Verdicts only move toward stricter enforcement during evaluation. A green verdict can become amber or red, never the reverse.
Identical inputs produce identical verdicts across every run. No sampling, no randomness, no stochastic decision paths.
The core evaluation engine has zero external runtime dependencies. It operates without network calls, LLM APIs, or third-party services.
Every identifier is HMAC-hashed with per-tenant keys before storage. Zero PII in HTTP responses, audit-log metadata, or telemetry; ephemeral event-store retention is opaque to external observers and expires within tenant retention window.
Every verdict produces an evidence packet with a deterministic content hash chain; HMAC signing attaches when the operator configures a signing key. Mutations are cryptographically detectable.
GreenLightz follows a data minimization principle. We process only what is needed for policy evaluation and store only hashed, non-reversible records.
| Data Type | Stored? | Detail |
|---|---|---|
| Verdicts and reasons | Yes | Evaluation outcomes with deterministic audit trail; sealed inside the Evidence Case that contains the AgentEvent. |
| AgentEvent action metadata | Yes | action_type, amount, currency, correlation_id — the fields the deployer's instrumentation posts to /v1/agent-events. |
| Hashed identifiers | Yes | SHA-256 HMAC with per-tenant keys — non-reversible. |
| Timestamps | Yes | ISO 8601, timezone-aware. |
| Policy configurations | Yes | YAML policy packs, version-controlled; policy_content_hash sealed into every Evidence Case. |
| Names, emails, phone numbers | No | Rejected at API ingestion — never reaches the engine or the Evidence Case. |
| Payment details or card numbers | No | AgentEvent ingest rejects 18 known PII field-name aliases across 11 families (email, phone, ssn, address, credit_card, ip_address, name, dob, passport, license, mrn and their paired variants) at the top of the request payload AND one dict level deeper. Payload string values are additionally scanned for SSN (\d{3}-\d{2}-\d{4}), 16-digit PAN, and RFC-5322 email patterns — matches are rejected with PII_METADATA_BLOCKED at 400. Free-form commitment text is accepted, stored ephemerally, hashed into the tamper-evident chain, and is NEVER echoed in HTTP responses, audit-log metadata, or structured telemetry. Identifiers upstream of ingest MUST be opaque (post the hash, not the PII). |
| Conversation transcripts | No | Not required for governance evaluation. |
| Customer IP addresses | No | Not logged, not stored, not used. |
| INTERNAL_ONLY hard-deny fields | No | Internal rule IDs, aggregate internals, signer key material, and sealer envelope bytes are stripped by the disclosure boundary before the Evidence Case leaves the engine. |
All API communication — /gateway/evaluate and /v1/agent-events — is encrypted in transit. HSTS enforced with 1-year max-age.
Each tenant has its own signing keys, policy pack, rate limits, and webhook credentials. Tenant ID is DERIVED server-side from the authenticated API key; it is never accepted from the request body. No cross-tenant data access; list_by_tenant() filters at the SQL level with concurrency-stress test coverage.
API keys are hashed before storage. Per-key rate limiting enforced. Credentials never appear in logs. Every /v1/* request runs through _require_gateway_auth + _check_operator_role + _enforce_tenant_binding before an Evidence Case is materialized.
Hosted on industry-standard managed cloud infrastructure with automated deployments. Key governance and claim-boundary properties are covered by automated test suites and release gates.
Concrete statements about how the /v1/agent-events → Evidence Case slice is bounded. Env-var names match docs/pivot/PIVOT_ENV_VARS.md.
The /v1/agent-events ingestion endpoint carries a per-tenant rate ceiling controlled by GLZ_PIVOT_V1_RATE_LIMIT_PER_MIN (default 6000/min). Excess requests are rejected with HTTP 429 before any Evidence Case is created; the gateway rate limiter is the same one that guards /gateway/evaluate.
The verdict seam /gateway/evaluate and the Evidence Case seam /v1/agent-events are separate Flask blueprints — neither route wraps the other. /v1/agent-events returns 503 UNSUPPORTED_ROUTE until an operator sets GLZ_PIVOT_V1_ENABLED=1. This is deliberate dark-deployment, not an outage. A first pilot integrates both seams; the buyer's helper unifies them. Compatibility diagram: docs/pivot/GATEWAY_VS_V1_SEAM.md.
When GLZ_PIVOT_V1_HMAC_KEY is set (Dashboard-only, never in the blueprint), the sealer emits packet_hmac_sha256 over the canonicalized packet body. The signing key is per-tenant, never logged, and never leaves the server. The sealed body is disclosure-boundary-sanitized BEFORE it is signed — the signature covers what a reviewer actually sees.
Every policy deploy, calibration signoff, approval resolution (surfaced only when the tenant has enabled the optional human-in-the-loop workflow; the engine's REQUIRE_APPROVAL autonomous verdict is emitted deterministically regardless), and packet seal emits a governance audit event to a JSONL chain. Each entry carries the previous entry's content hash, so a silent edit to any prior line breaks recomputation. audit_dropped_count is exposed via Prometheus so an operator sees dropped audits before the chain gap accumulates.
Internal rule IDs, aggregate internals, signer key material, calibration-session raw answers, and sealer envelope bytes are marked INTERNAL_ONLY by the disclosure boundary. They are stripped BEFORE the Evidence Case is written to the response, exported, or handed to a portal proxy. The whitelist is enforced by anti-drift tests keyed on field count.
The AgentEvent ingestion path, the Evidence Case materializer, the verdict evaluator, and the sealer contain zero LLM calls. No third-party API is invoked while an Evidence Case is being opened, evaluated, or sealed. The engine is Offline-First by invariant — LLM enrichment, when enabled at all, runs outside the verdict path.
integrity_chain_hash is the deterministic chained hash over the canonical AgentEvent, the policy pack content, the per-rule evaluation records, and the aggregate state. A reviewer can recompute the chain offline from the packet body; any silent mutation breaks recomputation. HMAC signing layers on top of this — tamper evidence does not require signing.
| GDPR data minimization | Implemented |
| Internal security hardening (scope-bounded) | Complete (scope-bounded) |
| SOC 2 Type II | In planning |
| ISO 27001 | In planning |
| External third-party penetration test | In planning |
Detailed security architecture is available for review under NDA during pilot evaluation.
Four things we want a security reviewer to see before they read anything else on this page. Each is a direct, plain-English non-claim — not a softening qualifier.
Evidence Cases and evidence packets are tamper-evident operational records. They are NOT audit-grade evidence. Your auditor determines admissibility, sufficiency, and methodology on their own terms.
An Evidence Case is not a legal attestation, not a court-ready exhibit, and not a determination of liability. Locally tamper-evident is not the same as legally admissible; external legal proof requires additional infrastructure your legal team specifies.
GreenLightz does not claim regulator-readiness. We do not represent that any Evidence Case will satisfy the disclosure or record-keeping obligations of any specific regulator. Interpretation of any regulatory framework is yours and your counsel's.
GreenLightz does not claim EU AI Act compliance. Our design principles (deterministic evaluation, tamper-evident chain, tenant isolation) align with themes discussed in the Act, but alignment with themes is a design posture — not a certification, not a compliance guarantee, and not a third-party attestation.
Verifiability-not-authority means we name what we do and do not yet have, so a procurement reviewer can map our posture to their requirements without ambiguity.
Security contact for responsible disclosure or technical review: [email protected].
GreenLightz follows an explicit claim-boundary discipline: every release-relevant claim has allowed and forbidden wording locked in a versioned registry, and reports cannot ship without underlying execution proof. We don't ship a claim until the underlying execution proof exists.
Each tagged release is gated by a 10-item manual seal that re-runs anti-slop, claim, scanner, and dependency checks. Local clean-room reproducibility — twin-run baseline plus hard-kill recovery — is part of every release seal.
This is the same evidence-bound discipline we apply to every customer commitment that flows through the API. We built it into our own engineering process before asking customers to rely on it.
We're happy to walk through our architecture in detail during a technical review.
Book a DemoEvery auto-allow at runtime is traceable to a customer-approved boundary captured during one-time calibration before go-live.
Operators answer a tiered question bank and judge boundary scenarios. Our deterministic compiler converts answers into a signed policy pack. No AI generates policy. Unresolved conflicts fail closed to a REQUIRE_APPROVAL autonomous verdict (deterministic; legacy alias per ADR SEC #504 §7.3) — routed to the optional human-in-the-loop workflow only when the tenant has enabled it.
Every Evidence Case references the deployed policy version. Policy version links to the calibration session via POLICY_DEPLOYED and CALIBRATION_SIGNED_OFF audit events. Auditor can reverse-trace any auto-allow back to a specific customer-approved boundary using the evidence_case_id (`case_id` accepted as legacy alias per ADR ONT-10 until 2027-01-12).
Calibration includes a forbidden-phrases list (legal claims, compliance promises, custom industry language). The evaluator pre-gate matches with Unicode normalization, whitespace tolerance, and word-boundary anchors before any rule evaluation.
Calibration signoff produces a content-addressed evidence reference with HMAC signature. Local tamper-evident — not legal-grade or WORM. External legal proof requires additional infrastructure. This is NOT legal/audit proof.