Every routed call is decided before it runs.
AASG, the Agentic AI Security Gateway, identifies the calling agent, authorizes each tool call against policy, records it in an append-only trail, and holds high-risk calls for human approval.
Preview policy outcomes Talk through a pilot
Built · development scope Gateway, policy engine, approvals, audit, evidence. Implementation reviewed 19 October 2026.
Concept · illustrative data
Three calls, one crossing
- Allowed refund-clerk reads one customer record. It runs and is recorded.
- Denied acme-agent-07 tries to delete production records. Stopped at policy; the denial is recorded.
- Approval refund-clerk posts fourteen refunds. The hold is recorded immediately; a person decides whether to release it.
Demos on this page use illustrative data from the Acme Bank demo workspace, except the policy pack below the policy section, whose reference outcomes were checked against the real policy engine. These examples call no backend. Hashes and receipts shown are not valid signatures.
Identity first: every call has a named caller
Before anything else, the gateway identifies the calling agent. Each tool call arrives with an agent identity the gateway can check, so policy and the audit trail both attach to something concrete: which agent acted, with which credentials, under which delegation.
- Per-agent identity for tool calls, separate from the human user who started the task.
- Short-lived credentials from the broker instead of permanent secrets where supported.
- Delegated calls carry the chain: parent, child, and the scope each link was granted.
Example · illustrative data
A configured SDK guard submits a read request as refund-clerk. Policy evaluates that agent and its session. The audit record carries context; the receipt binds agent, tenant, tool-call ID, and decision. The current credential broker mints GitHub App installation tokens, not arbitrary CRM credentials.
External research reports time to remediate leaked secrets, not how long every leaked token remains usable (how delegation stays bounded), and one agent-hijacking test moved success rates sharply once the agent could act (evidence below).
Tool-Use Gateway: the evaluate and complete paths
In the SDK path, evaluate authenticates the caller, evaluates policy, records the decision, and returns its receipt before execution. The integrated executor runs a permitted call; complete records the status and output it reports. Complete does not execute the tool or issue the initial receipt. The MCP proxy is a separate path that forwards permitted calls itself.
- Authenticate. Check the agent identity and the credential it presented.
- Evaluate. Apply policy priority and first-match ordering; the most restrictive result at the deciding priority wins.
- Release, reshape, or hold. Allow, deny, redact, require approval, log only, or escalate.
- Execute and record. The integrated executor runs a permitted call and reports completion; audit sequence assignment is asynchronous.
- Receipt. Evaluation signs the decision before execution. Proof bundles and a separately trusted key support offline checks.
The full crossing, stage by stage, is drawn on the architecture page.
Example · illustrative data
One read allowed, one posting held
- refund-clerk / customers.read
- One customer record. Rule refunds-read-own-queue matches — runs, recorded, receipted.
- Allowed
- refund-clerk / refunds.post
- Fourteen refunds. Above the clerk limit — the pending decision is recorded and receipted before human review.
- Approval
Deterministic policy: the same call, the same answer
Policy evaluation is deterministic: the same full context, policy ordering, and engine configuration yield the same outcome. No model takes the final decision on a critical allow or deny; the engine applies priority and rule ordering. Within the deciding priority group, the most restrictive first-match result wins.
In plain terms: a rule names a caller, a tool, and a condition — for example, “refund clerks may read records from their own queue” — and the engine answers allow, deny, redact, approval, log-only, or escalation. Deny wins among contributing matches at the deciding priority, not across every rule regardless of order.
| Outcome | What happens |
|---|---|
allow | The call runs as requested. |
deny | The call is stopped; the denial is recorded with the rule that fired. |
redact | Matched sensitive fields are masked; the integrated executor must use the returned input. |
require_approval | The call waits in the approval inbox until a person releases or rejects it. |
log_only | The call runs, recorded as an explicit nonblocking policy outcome. |
escalate | The call is held as an escalated approval request, with configured routing context. |
Rules, conflict handling, and monitor-vs-enforce modes are detailed on the policy page.
Policy packs: rules you install, not write
A policy pack is a versioned set of ready-made rules. The one shown here is
Coding Agent — Shell Command Governance
(coding-agent-shell-guard, version 1.0, six rules). It is made for autonomous
coding agents such as Claude Code.
- Denies matching patterns for Read, Write or Edit requests whose file path names a
.envfile, Bash strings matching its.envpattern (the pattern excepts example-file names), and listed destructive command strings such asrm -rf,git reset --hardorDROP TABLE. - Requires approval for matching bulk-delete patterns such as
find … -delete, for listed command strings with external effects (git push,npm publish,terraform apply), and for any other Bash command outside its short allowlist. - Has no allow rule. Calls none of its rules match, such as commands on its allowlist (
ls,grep,git status, and certain test invocations) or a Read, Write or Edit of any file other than.env, are decided by the tenant's other policies or, failing those, by the default action.
A pack installs in monitor mode first. The figure evaluates this pack alone in enforce mode. Other policy priorities and rule order can change the deciding result in a combined configuration. These string patterns do not parse every shell execution or resolve indirect file access; installation alone does not intercept a coding agent. Its calls must be routed through an integration.
Six tool calls a coding agent can make, each evaluated against this pack alone, in enforce mode. These are checked reference results; the animation calls no backend.
- Bash
ls docs/default action no_matching_rule - Edit
src/app/page.tsxdefault action no_matching_rule - Read
.envdenycasg-000 - Bash
cat .envdenycasg-002 - Bash
git push origin mainrequire_approvalcasg-004 - Bash
rm -rf builddenycasg-001
Each outcome is what the Ghalta policy engine returned for that call with only this pack loaded. no_matching_rule: none of the pack's rules matched, so the default action applies: deny, unless a development deployment sets allow. A tenant can make it stricter, never looser.
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.
Dry-run evaluates a supplied tool-call context against a stored policy without executing it. Replay compares a bounded sample of recorded calls with a selected policy and reports differences and reconstruction limits. Archived versions preserve policy context, not an exact replay guarantee.
| Call | v4 outcome |
|---|---|
refunds.clerk reads one customer record, own queue | allow |
refunds.clerk deletes production records | deny rule refunds-no-delete |
support.agent sends a message containing account numbers | redact fields masked |
ledger.writer exports the full ledger | require_approval held for a person |
Enforce: outcomes bind as written.
Illustrative data; nothing here changes real policy.
Example · illustrative data
A candidate rule — deny ledger exports over a thousand rows — replays a sample of last week's calls and reports that one export would have been denied and the rest untouched. The team promotes the rule only once that preview matches their intent.
The dry-run and replay previews are on the policy page.
Try it: what each outcome does to a call
Pick an outcome to see the path an illustrative call takes. Demo data only: Acme Bank demo workspace, a refund clerk agent asking to read one customer record. The same six outcomes appear in the table above, so the switcher adds a walk-through, not hidden content.
Policy outcome
allow — the call runs as requested.
Path: authenticate → evaluate (rule refunds-read-own-queue matches) → record decision + receipt → integrated execution → report completion.
Approvals: a person decides the risky calls
Calls with require_approval or escalate wait in an approval inbox
instead of running. A reviewer sees who asked, what the call would do, which rule held it,
and the delegation chain behind it — then releases or rejects it. The decision itself is
recorded and receipted like any other.
- High-risk actions wait for a person; nothing times out into an allow.
- Release and rejection both land in the audit trail with the reviewer identity.
- Approval release rechecks policy state and records the reviewer decision; approval is not an unconditional bypass.
Example · illustrative data
The clerk's fourteen-refund posting waits in the inbox: caller refund-clerk, rule clerk-limit-10, amount above the clerk limit. The reviewer releases or rejects it with one action; either way the decision is recorded under the reviewer's name.
Audit and evidence: recorded, checkpointed, receipted
Evaluation records an audit event and a compact Ed25519-signed decision receipt. Background work assigns audit sequences and creates signed Merkle checkpoints. A proof bundle links the receipt to its audit event and checkpoint for ghalta-verify; checkpoint availability can lag evaluation. A denial may still be returned when signing fails. Demo hashes are illustrative.
How the trail answers the audit question is on the evidence page.
-
unclear if there are fool-proof methods of prevention
OWASP says it is unclear whether any method fully prevents prompt injection; the measures it lists mitigate the impact.
Given the stochastic influence at the heart of the way models work, it is unclear if there are fool-proof methods of prevention for prompt injection.
Source: OWASP GenAI Security Project, retrieved
-
from 11% for the strongest baseline attack to 81% for the strongest new attack
In a NIST test of one AI agent, attacks built for that agent hijacked it far more often than the best known attack.
This resulted in an increase in attack success rate from 11% for the strongest baseline attack to 81% for the strongest new attack.
Source: NIST Center for AI Standards and Innovation (CAISI), retrieved
Next
- Policy engine — outcomes, deny-wins, dry-run and replay.
- Evidence and receipts — trail, checkpoints, offline verification.
- Multi-agent delegation — chains, scopes, taint, kill switch.
- Architecture — the full request path across stacks.
- Contact — talk through a gateway pilot.
Ghalta is in early development: this page describes a problem and an approach, not a finished product.