Policy the same way every time.
Each tool call is evaluated by the AASG (Agentic AI Security Gateway) against versioned policy: allow, deny, redact, require approval, log only, or escalate. Policies run by priority; the first matching rule in each policy contributes, and the most restrictive result at the deciding priority wins. AI does not make the final critical allow or deny decision.
Built Implemented policy engine: 17 operators, monitor and enforce policies, archived versions.
Concept · illustrative data
One call, one deciding group
Lowest priority number first. One first match per enforce policy; the most restrictive result wins within the deciding group.
Six outcomes, ordered evaluation
Policies are evaluated from lower numeric priority to higher. The first definite matching rule in each enforce policy contributes to that priority group. The most restrictive result wins within that group; lower-priority groups are skipped once it decides. A deny in a later rule of the same policy or a lower-priority policy does not globally override an earlier allow. Internal evaluation errors fail closed.
Example · illustrative data
A ledger export matches team-exports-allow and
exports-no-full-ledger. With both policies at the same deciding priority and each deny or allow as its first matching rule, deny wins. The audit context names the deciding rule; the compact signed receipt records the decision and call identity.
| Outcome | Effect |
|---|---|
allow | Runs as requested. |
deny | The integrated executor stops the call; the decision is recorded. |
redact | Returns masked input for the integrated executor to use. |
require_approval | Held in the approval inbox until a person decides. |
log_only | Runs; the explicit nonblocking outcome is recorded. |
escalate | Held as an escalated approval request; configured routing context is recorded. |
Operators: the vocabulary rules are written in
The implemented operator vocabulary has 17 operators. Field availability depends on the call context; the engine does not query arbitrary history during evaluation.
Rules combine operators into allow, deny, redact, approval, log-only, and escalation clauses, versioned together so a past decision can always be read against the version that made it.
| Kind | Operators |
|---|---|
| Comparison | equalsnot_equals |
| Membership | innot_in |
| Containment | containscontains_anycontains_all |
| Pattern | matches_regexnot_matches_regex |
| State | is_trueis_falseis_nullis_not_nulllist_empty |
| Numeric | greater_thanless_than |
| Reputation | mcp_reputation_below |
Monitor first, enforce when ready
A pack installs in monitor mode. A policy written by hand starts as a draft, which is never evaluated, and can be promoted to monitor or straight to enforce. A monitored rule never decides a call: enforced rules decide it, and if none matches, the default action does. In that case the decision record names the first monitored rule that matched, so the team sees what the rules would do before they bind. In enforce mode the rules decide.
The default action is deny, unless a development deployment sets
allow. A tenant can make it stricter, never looser.
The AASG page runs the comparison live: the same four illustrative calls under monitor versus enforce.
Dry-run: test a supplied call context
Dry-run evaluates one saved policy against a supplied tool-call context without executing a tool. A draft is treated as enforce for this preview. Comparing recorded history is the separate replay operation; the browser example here illustrates a candidate comparison and makes no API call.
Candidate rule
deny ledger exports over 1000 rows
No dry-run yet. The candidate rule is shown for preview; run it to see the effect on the four illustrative calls on the AASG page.
Replay: read history through a new version
Replay re-evaluates a bounded sample of recorded calls against the selected policy and reports differences. Its response includes reconstruction fidelity and unreplayable fields: retained snapshots and available historical context limit what can be reproduced. Archived policies preserve versions; they do not make every replay exact.
Policy version
v4 vs v3 on the four calls: delete goes allow → deny; message with account numbers goes allow → redact. Reads and the held export are unchanged.
v3 predates rules refunds-no-delete and messages-mask-accounts; v4 adds both. Illustrative versions.
Policy packs and archived versions
Policy packs are versioned starting rule sets. Teams install and adjust them, preview supplied contexts or replay a historical sample, then choose monitor or enforce.
Policy and audit records provide version context separately from the compact receipt — see the evidence page for the distinction between compact receipts and separate policy records.
Next
- Evidence and receipts — decision records, signatures, and checkpoint proofs.
- AASG gateway — where evaluation sits in the call path.
- Multi-agent delegation — the checks every hop faces.
- Contact — talk through a policy pilot.
Ghalta is in early development: this page describes a problem and an approach, not a finished product.