SDKLocal rules & redaction

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):

OperatorMeaning
==, !=equals / not equals
>, >=, <, <=numeric / lexicographic comparison
in, not_inmembership in an array value
containsstring/array contains value
startsWith, endsWithstring prefix / suffix
matchesregex test (value is a pattern)
existsthe 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"|undefined

Redaction

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.