Build Zero-Trust AI Agents with AgentTrust Runtime

An autonomous support and refund agent

Take a common pattern: an autonomous customer-support agent handling order returns. In normal operation it reads a customer request, computes a restocking deduction, writes the approved refund to the ledger, and returns a confirmation. AgentTrust demos this as a payment-refund agent — an agent identifier that matches the financial policy pack.

Illustration of the refund workflow. AgentTrust's live UI is the operator dashboard — events, trace replay, review queue — not an end-user chat screen.

Now consider an attacker submitting this prompt.

Without a pre-check, that single prompt can trigger an unauthorized payout, leak API keys, or write a hallucinated refund with no amount field at all. The AgentTrust refund demo walks the same workflow in six acts: approve a well-formed $85 refund, block a missing amount, block an unverified external recipient, retry an ungrounded transfer, raise a blocked-action error before the function body runs, then replay the audit trail.

The same broken payment, with and without a gate, is the argument for putting policy outside the model. Ungoverned agents ship the tool call. Governed agents raise a blocked-action error first.

Sign every decision: hash-chained audit identity

In most multi-agent architectures, every worker process talks to the database with the same shared connection. If an agent is tricked into modifying records — or if someone edits a row after the fact — there is no cryptographic proof connecting that mutation to a governed decision.

AgentTrust does not sign the SQL row with a cloud key-management service. It signs the governance envelope. After validation, confidence, risk, and decision scoring run, the audit store appends an execution record whose ledger hash is chained to the previous row.

# ledger_hash = SHA256(previous_ledger_hash || content_hash)
def _compute_ledger_hash(previous: str, content_hash: str) -> str:
    payload = (previous + content_hash).encode("utf-8")
    return hashlib.sha256(payload).hexdigest()

# Persisted under a row lock on ledger_state
row.ledger_hash = _compute_ledger_hash(prev.ledger_hash, row.content_hash)

An independent verifier walks the chain. If a rogue process changes a $149.00 refund to $10,000.00 in the application database, that is a separate integrity problem — but the governance record still shows the original envelope, decision, and policy version. Operators verify the chain through a dedicated audit endpoint. PII can later be nulled through the same audit API while hashes remain, so erasure requests don't silently rewrite history.

Gate inputs and outputs: deterministic validation

Business rules — refund maximums, required fields, secret filtering — should not rely on the model complying with a prompt. AgentTrust's design is an envelope: the SDK sends the proposed action or completed output to the gateway, validation and policy engines score it, and a decision engine maps scores onto approve, block, retry, escalate, or request-evidence.

Guardrails as YAML

Compliance should own rules a reviewer can actually read. Policy packs match by agent identifier glob — a pattern like payment-* auto-loads the financial pack.

# Auto-activates for payment-*, billing-*, invoice-*, transfer-*
rules:
  - id: payment_amount_present
    severity: critical
    target: output.amount
    op: exists
    effect: deny              # missing amount → policy_score 0 → BLOCK
  - id: payment_amount_positive
    severity: critical
    target: output.amount
    op: gt
    value: 0

A separate global control set denies output shaped like a social security number with a critical not-matches rule, and a payment amount ceiling rule caps refunds at a high severity threshold — high severity routes to human review rather than an automatic critical block, so the dollar cap alone does not catch the jailbreak string above. That's the adversarial gate's job.

Regex adversarial gate — not an LLM

The validation engine scans the request input and the serialized output. Any injection-pattern hit sets the policy score to the minimum of its current value and 20, and records a failure such as an instruction-override attempt. The decision engine blocks whenever the policy score falls below 60.

adversarial_patterns:
  - id: instruction_override
    source: "(?i)\\bignore\\s+(previous|all|above)\\s+instruction"
    severity: critical
    description: "Prompt injection: instruction override attempt"

# if any pattern hits:
if hits:
    policy_score = min(policy_score, 20)
    safety_score = 20

Decision tree, not just allow or deny

The decision engine reads a thresholds table: auto-approve at confidence 90 and above, block below confidence 50 or a policy score under 60, escalate on critical risk (or high risk with confidence under 80), retry in the 50–70 confidence band, otherwise request evidence.

That graduated set is the point. Allow/deny is not enough for a refund agent that sometimes needs a human. A trace-replay view in the dashboard walks schema, tool trust, policy, grounding, consistency, confidence, risk, and decision on a stored envelope — the operator's equivalent of a refund-policy screenshot.

How AgentTrust OS closes the loop

The refund agent still needs a pre-production attack suite, an inline gate, and proof after the fact. Those are three products, not one checkbox.