KYC and AML review

The secret and reveal builtins keep PII out of logs by construction, and capability grants let you prove a component never had network access.

The problem

Know-your-customer workflows combine document OCR, entity matching, and sanctions screening. The sensitive parts - passport numbers, account identifiers, watchlist hits - must not appear in application logs, error reports, or the stdout of a debugging session. Policy documents say "do not log PII"; code review tries to enforce it; neither scales.

Compliance also asks whether the screening step could have phoned home. A dependency update that adds a hidden HTTP client is a recurring nightmare in Python and Node ecosystems.

Why Ecko

Secrets by type: secret(v) wraps a value so print, json_encode, and stack traces redact it automatically. reveal is explicit - auditors can grep for every place sensitive data becomes plain text.
Capability grants: Give a package "grant": [] in ecko.json and it is mechanically unable to open sockets or spawn processes, regardless of what its transitive dependencies declare. You can point review at the grant line, not a 200-page SBOM.
Offline mock mode: CI runs the same review logic against deterministic mock responses - no API keys, no sandbox data leaking to a vendor - so policy tests are real tests.

In practice

screen.ecko

# ecko.json grants the screening package nothing, so it cannot open a socket:
#   "screening": { "path": "github.com/acme/screening", "grant": [] }

fn screen(name, passport) {
    print("screening {name}, passport {passport}")  # prints [secret] twice
    ai "Summarise sanctions risk for: {reveal(name)}"  # the one exposure point
}

summary = screen(secret("Ada Lovelace"), secret("P1234567"))

Related cases

Insurance claims intake Typed extraction into structs beats prompt-and-parse, and JSONL tracing gives you a per-claim audit trail with token and cost attribution.

All 9 use cases →

Try it on your workload.

Install Ecko Open the playground