Local rules & redaction
Two client-side features that make Eda faster and safer: local rules (decide the obvious cases without a network call) and redaction (never send secrets you didn’t mean to).
Local rules
A local rule is a deterministic pre-check evaluated in your process before the
API is called. If a local rule matches with a terminal effect (block/allow),
Eda can short-circuit; require still routes to the server for the human approval
flow. Local rules are great for latency-sensitive hot paths and for encoding
invariants you never want to depend on the network for.
import { Eda, rule } from "@eda-holding-inc/sdk";
const eda = new Eda({
apiKey: process.env.EDA_API_KEY!,
localRules: [
// Never let any agent delete the production database — no round-trip needed.
rule().agent("*").action("delete_database").where("env", "==", "production").block(),
// Refunds over $500 always need a human.
rule().agent("*").action("refund_*").where("amount", ">", 500).require(),
// Read-only actions are always fine.
rule().action("get_*").allow(),
],
});The rule() builder
Fluent and chainable:
rule()
.agent("support-*") // glob on agent (default "*")
.action("refund_customer") // glob on action (default "*")
.where("amount", ">", 500) // zero or more conditions (AND-ed)
.where("currency", "==", "USD")
.require(); // terminal: .block() | .allow() | .require()Condition operators
where(path, op, value) — path is a dot-path into params
("customer.tier"). Supported op values (ConditionOp):
| Operator | Meaning |
|---|---|
==, != | equals / not equals |
>, >=, <, <= | numeric / lexicographic comparison |
in, not_in | membership in an array value |
contains | string/array contains value |
startsWith, endsWith | string prefix / suffix |
matches | regex test (value is a pattern) |
exists | the path is present (no value needed) |
Local rules and server policies share the same operator set and semantics, so a rule you prototype locally translates directly into a dashboard policy.
Evaluating rules yourself
The primitives are exported if you want to run them standalone:
import { evaluateLocalRules, matchesRule, evaluateCondition } from "@eda-holding-inc/sdk";
const effect = evaluateLocalRules(rules, { agent, action, params }); // "allow"|"block"|"require"|undefinedRedaction
Parameters are stored in the audit log so you can see what an agent tried to do.
Some params shouldn’t leave your process — passwords, tokens, full card numbers.
Eda redacts a default set of sensitive keys before anything is sent, replacing
values with "[REDACTED]".
import { Eda, DEFAULT_REDACT_KEYS, redact, REDACTED } from "@eda-holding-inc/sdk";
const eda = new Eda({
apiKey: process.env.EDA_API_KEY!,
// extend or replace the default redaction list
redactParams: [...DEFAULT_REDACT_KEYS, "ssn", "apiSecret"],
});DEFAULT_REDACT_KEYS covers common cases (password, token, secret,
authorization, apiKey, creditCard, cvv, …). You can redact ad-hoc data too:
const safe = redact({ email: "a@b.com", password: "hunter2" }, ["password"]);
// → { email: "a@b.com", password: "[REDACTED]" }Redaction changes what Eda can evaluate. If you redact a key, don’t also write a
server policy condition on that key — it won’t see the real value. Keep
decision-relevant params (like amount) unredacted, and redact only secrets.