For the security sign-off

Your agents propose. Your policy grants.
Nothing else runs.

The rollout waits on your signature. The agent holds no credential, and every grant leaves a signed receipt.

For the security sign-off

Your agents propose. Your policy grants. Nothing else runs.

The rollout waits on your signature. The agent holds no credential, and every grant leaves a signed receipt.

The rollout reaches your desk either way. The teams that ship agents control exactly this risk.

8.5%of indirect injections still succeed against the most injection-robust model measured, within 15 attempts
97%of breached organizations that had an AI-related incident lacked proper AI access controls

8.5%: OpenAI, GPT-6 Astra system card, 2026-09-03, n = 1,810 attacks, 15 attempts. 97%: IBM, Cost of a Data Breach 2025, n = 600 organizations, of the 13% that reported an AI breach. Chart: McKinsey Global Survey, “The state of AI in 2026: On the road to ROI,” n = 1,719, May–June 2026 (Exhibit 15).

Share working to mitigate each AI risk, % of respondents

AI high performersAll others
Share of respondents working to mitigate each AI risk, AI high performers versus all others
RiskAI high performersAll others
Unauthorized or unintended agent action45%33%
AI-driven exploitation of vulnerabilities56%46%
Inaccuracy53%52%
Personal privacy33%36%
The gap appears only on the agent-authority risks; commodity risks show none.

The rollout reaches your desk either way. The teams that ship agents control exactly this risk.

8.5%of indirect injections still succeed against the most injection-robust model measured, within 15 attempts
97%of breached organizations that had an AI-related incident lacked proper AI access controls

Share working to mitigate each AI risk, % of respondents

AI high performersAll others
The gap appears only on the agent-authority risks; commodity risks show none.

8.5%: OpenAI, GPT-6 Astra system card, 2026-09-03, n = 1,810 attacks, 15 attempts. 97%: IBM, Cost of a Data Breach 2025, n = 600 organizations, of the 13% that reported an AI breach. Chart: McKinsey Global Survey, “The state of AI in 2026: On the road to ROI,” n = 1,719, May–June 2026 (Exhibit 15).

Probabilistic systems don’t have zeros.

Your agents read email, tickets and documents you don’t control. Whoever writes to those writes to the agent.

Assume the injection works. A model fooled 2% of the time and one fooled every time meet the same grant.

via an email it summarizesHidden text in the message tells the agent to forward what it can reach. The data leaves your tenant. Refused: no rule grants that send.
via a ticket it readsA poisoned ticket becomes a destructive write to production, authorized because the agent held the credential. Held: quorum 2-of-2, not met.
via a document it fetchesA fetched page moves a payment to a new payee. Nothing records who authorized it, because nobody did. Held for two named humans.

Anyone who can put text in front of an agent can act with its credentials: an email, a ticket, a PDF, a web page. Tool descriptions are the fastest-growing channel. OWASP LLM01:2025: no fool-proof prevention of prompt injection is known. UK NCSC, 2025-12-10: it may never close the way SQL injection did.

Probabilistic systems don’t have zeros.

Your agents read email, tickets and documents you don’t control. Whoever writes to those writes to the agent.

Assume the injection works. A model fooled 2% of the time and one fooled every time meet the same grant.

via an email it summarizesHidden text in the message tells the agent to forward what it can reach. The data leaves your tenant. Refused: no rule grants that send.
via a ticket it readsA poisoned ticket becomes a destructive write to production, authorized because the agent held the credential. Held: quorum 2-of-2, not met.
via a document it fetchesA fetched page moves a payment to a new payee. Nothing records who authorized it, because nobody did. Held for two named humans.

Anyone who can put text in front of an agent can act with its credentials: an email, a ticket, a PDF, a web page. Tool descriptions are the fastest-growing channel. OWASP LLM01:2025: no fool-proof prevention of prompt injection is known. UK NCSC, 2025-12-10: it may never close the way SQL injection did.

The platform

Agent authorization, between your agents and everything they touch.

We don’t filter prompts. The agent can be manipulated end to end and still change nothing, because it holds nothing.

01 · The agent edge

Every action starts as a proposal. The agent holds one ZIFFER key that can ask, not act — a structured proposal against a catalog you define.

  • Via MCP, your catalog is the agent’s toolset. An out-of-catalog action can’t even be expressed.
  • Or one SDK call, or plain HTTPS. Your agent, model and prompts don’t change.
  • Least privilege, evidenced by absence: there is no credential in the agent for an auditor to review

02 · The product

Your signed policy decides. Grant by policy, hold by exception: machine speed for the routine, two named humans for the irreversible.

  • Granted in milliseconds when your rules say LOW
  • Held for a quorum when they say HIGH: dual authorization, each approver signing the exact bytes that will run. Silence is never consent.
  • Refused by default when no rule exists. Unknown is never LOW.

03 · Enforcement

Only granted actions ever run. ZIFFER re-issues the intent with its own credential — the grant can’t be bypassed.

  • Your systems accept actions only from ZIFFER’s identity: one scoped credential per system, one CloudFormation stack to set up.
  • Access enforcement your auditor can test: send the same call around ZIFFER and watch it fail
  • What was granted is exactly what ran: recomputed at execution, never trusted from the message.

04 · Evidence

A signed receipt for everything that ran. An append-only ledger, anchored externally before an irreversible action releases.

  • Hybrid post-quantum signatures (Ed25519 + ML-DSA-65)
  • Nobody rewrites history — not us, not your own admin
  • Non-repudiation your auditor verifies with a public CLI, without production access

05 · The policy supply chain

Rules are signed offline. Publishing ends in a signing ceremony — never a Save button. Even a fully compromised ZIFFER can’t rewrite them.

  • No runtime component holds a key that can produce a valid policy signature, so the runtime path has nothing worth stealing.
  • Policy Engine, KMS and Executor each verify the bundle independently, on every read: a service handed policy by a peer would just be trusting that peer.
  • Signed change control: epochs only increase, so a rollback to yesterday’s looser rules is refused

The platform

Agent authorization, between your agents and everything they touch.

We don’t filter prompts. A manipulated agent still changes nothing: it holds nothing.

01 · The agent edge

Every action starts as a proposal. The agent holds one ZIFFER key that can ask, not act.

  • Via MCP, your catalog is the agent’s toolset. An out-of-catalog action can’t even be expressed.
  • Or one SDK call, or plain HTTPS. Your agent, model and prompts don’t change.
  • Least privilege, evidenced by absence: there is no credential in the agent for an auditor to review

02 · The product

Your signed policy decides. Grant by policy, hold by exception: machine speed for the routine, two named humans for the irreversible.

  • Granted in milliseconds when your rules say LOW
  • Held for a quorum when they say HIGH: dual authorization, each approver signing the exact bytes that will run. Silence is never consent.
  • Refused by default when no rule exists. Unknown is never LOW.

03 · Enforcement

Only granted actions ever run. ZIFFER re-issues the intent with its own credential — the grant can’t be bypassed.

  • Your systems accept actions only from ZIFFER’s identity: one scoped credential per system, one CloudFormation stack to set up.
  • Access enforcement your auditor can test: send the same call around ZIFFER and watch it fail
  • What was granted is exactly what ran: recomputed at execution, never trusted from the message.

04 · Evidence

A signed receipt for everything that ran. An append-only ledger, anchored externally.

  • Hybrid post-quantum signatures (Ed25519 + ML-DSA-65)
  • Nobody rewrites history — not us, not your own admin
  • Non-repudiation your auditor verifies with a public CLI, without production access

05 · The policy supply chain

Rules are signed offline. Publishing ends in a signing ceremony — never a Save button.

  • No runtime component holds a key that can produce a valid policy signature, so the runtime path has nothing worth stealing.
  • Policy Engine, KMS and Executor each verify the bundle independently, on every read: a service handed policy by a peer would just be trusting that peer.
  • Signed change control: epochs only increase, so a rollback to yesterday’s looser rules is refused

What you hand the auditor

Every action, one line. Reproducibility is provenance over results. This is provenance over actions.

What you hand the auditor

Every action, one line. Reproducibility is provenance over results. This is provenance over actions.

The sign-off checklist

Six properties. Four enforced by a published clause, two by construction.

Zero credentials in the agent

Not vaulted, not brokered, not short-lived — the agent never touches a secret. Nothing to leak into a context window.

Bypass impossible, not monitored

Your systems accept actions only from ZIFFER’s identity. Going around ZIFFER hits a wall, not an alert.

Refusal by default8.4-3 · P-4

An action with no rule is refused, never graded. Unknown risk is never LOW.

Consent is explicit & boundAC-3(2)

Dual authorization: the quorum is two named humans, each signing the exact bytes that will execute. The proposer can’t approve their own action.

Receipts, not logsAU-10 · AU-3

Every action carries a KMS-signed receipt binding the action, the rules that graded it and the humans who signed.

History nobody can rewriteAU-9(3)

Append-only ledger, anchored externally before an irreversible action releases.

The clause IDs are real. ZIFFER implements an open specification, and every claim replays on your machine: ./tools/verify.sh --suites

The sign-off checklist

Six properties. Four enforced by a published clause, two by construction.

Zero credentials in the agent

Not vaulted, not brokered, not short-lived — the agent never touches a secret. Nothing to leak into a context window.

Bypass impossible, not monitored

Your systems accept actions only from ZIFFER’s identity. Going around ZIFFER hits a wall, not an alert.

Refusal by default8.4-3 · P-4

An action with no rule is refused, never graded. Unknown risk is never LOW.

Consent is explicit & boundAC-3(2)

Dual authorization: the quorum is two named humans, each signing the exact bytes that will execute. The proposer can’t approve their own action.

Receipts, not logsAU-10 · AU-3

Every action carries a KMS-signed receipt binding the action, the rules that graded it and the humans who signed.

History nobody can rewriteAU-9(3)

Append-only ledger, anchored externally before an irreversible action releases.

The clause IDs are real. ZIFFER implements an open specification, and every claim replays on your machine: ./tools/verify.sh --suites

Pricing

Three arrangements. One question: who checks you?

In development

Standard

“Do you check yourself?”

  • Hosted ZIFFER, admin & approval consoles
  • Signed receipts, per-tenant signing key
  • Hosted external anchoring, auditor CLI
  • MCP / SDK / HTTPS integration
  • Onboarding starts within 48 hours
Book a 30-min sign-off review
In development

Assured

“Does someone independent check you?”

  • Separated verification domain
  • Receipt keys in your cloud account — we cannot forge your receipts, and you can revoke us
  • Every signature lands in your audit trail
Book a 30-min sign-off review
In development

Regulated

“Does a regulator dictate how your keys are held?”

  • Mandated custody arrangements
  • HSM-held keys under external mandate
  • For deployments where the key mechanism is prescribed
Book a 30-min sign-off review

Pricing

Three arrangements. One question: who checks you?

In development

Standard

“Do you check yourself?”

  • Hosted ZIFFER, admin & approval consoles
  • Signed receipts, per-tenant signing key
  • Hosted external anchoring, auditor CLI
  • MCP / SDK / HTTPS integration
  • Onboarding starts within 48 hours
Book a 30-min sign-off review
In development

Assured

“Does someone independent check you?”

  • Separated verification domain
  • Receipt keys in your cloud account — we cannot forge your receipts, and you can revoke us
  • Every signature lands in your audit trail
Book a 30-min sign-off review
In development

Regulated

“Does a regulator dictate how your keys are held?”

  • Mandated custody arrangements
  • HSM-held keys under external mandate
  • For deployments where the key mechanism is prescribed
Book a 30-min sign-off review

Objections, answered

The questions the approval meeting actually asks.

Doesn’t human approval kill agent speed?

Most of the day passes untouched. Your rules grant the routine set in milliseconds, and only actions nobody can take back are held. A gate that fires on everything is approved on reflex, and OWASP lists that reflex as a threat of its own. So the holds are few, and each arrives with the provenance the machine already has: who proposed it, on what context, at what consequence. That is a dimmer, not a kill switch, and a grant can be revoked without touching the agent.

Why not build this with our own IAM?

Your IAM answers whether an identity may reach a system. It does not answer whether this action was entitled to happen: a credential is not authorization. The gate loop itself is a weekend. What isn’t: machine-checked invariants, hybrid post-quantum signed receipts, an externally anchored ledger your own admin can’t rewrite, and a public conformance suite proving all of it. If you do build it, build to the open specification; the suites will tell you what your version misses.

How long does integration take, and what changes for the agent team?

Minutes on the agent edge: via MCP, ZIFFER publishes your action catalog as the agent’s tools; or one SDK call; or plain HTTPS. Once per protected system, a scoped credential only ZIFFER can use. Onboarding starts within 48 hours. Your agent, model, framework and prompts don’t change.

Who checks you?

Nobody independent, yet: no third party has run an adversarial review, and we would rather write that here than let you discover it. What you can check today without us: the open specification, the reference implementation under Apache 2.0, the attack suites that replay on your laptop with each control deleted in turn, and the residual-risk file we published before the claims. On Assured the receipt keys live in your own cloud account, so we cannot forge your receipts and you can revoke us unilaterally.

What do I get from the sign-off review?

Thirty minutes, and you leave with a sign-off memo rather than a deck: your rollout’s properties mapped to the controls you already own, the list of actions we would hold for two named humans, and a sample of the evidence an auditor would receive. If the honest answer is that you don’t need us, the memo says that.

Objections, answered

The questions the approval meeting actually asks.

Doesn’t human approval kill agent speed?

Most of the day passes untouched. Your rules grant the routine set in milliseconds, and only actions nobody can take back are held. A gate that fires on everything is approved on reflex, and OWASP lists that reflex as a threat of its own. So the holds are few, and each arrives with the provenance the machine already has: who proposed it, on what context, at what consequence. That is a dimmer, not a kill switch, and a grant can be revoked without touching the agent.

Why not build this with our own IAM?

Your IAM answers whether an identity may reach a system. It does not answer whether this action was entitled to happen: a credential is not authorization. The gate loop itself is a weekend. What isn’t: machine-checked invariants, hybrid post-quantum signed receipts, an externally anchored ledger your own admin can’t rewrite, and a public conformance suite proving all of it. If you do build it, build to the open specification; the suites will tell you what your version misses.

How long does integration take, and what changes for the agent team?

Minutes on the agent edge: via MCP, ZIFFER publishes your action catalog as the agent’s tools; or one SDK call; or plain HTTPS. Once per protected system, a scoped credential only ZIFFER can use. Onboarding starts within 48 hours. Your agent, model, framework and prompts don’t change.

Who checks you?

Nobody independent, yet: no third party has run an adversarial review, and we would rather write that here than let you discover it. What you can check today without us: the open specification, the reference implementation under Apache 2.0, the attack suites that replay on your laptop with each control deleted in turn, and the residual-risk file we published before the claims. On Assured the receipt keys live in your own cloud account, so we cannot forge your receipts and you can revoke us unilaterally.

What do I get from the sign-off review?

Thirty minutes, and you leave with a sign-off memo rather than a deck: your rollout’s properties mapped to the controls you already own, the list of actions we would hold for two named humans, and a sample of the evidence an auditor would receive. If the honest answer is that you don’t need us, the memo says that.

Keep the intelligence. Remove the authority.

You are the one being asked to approve it. Thirty minutes, and you leave with the memo you would sign.

Onboarding within 48 hours · open spec · verify before you pay

Keep the intelligence. Remove the authority.

You are the one being asked to approve it. Thirty minutes, and you leave with the memo you would sign.

Onboarding within 48 hours · open spec · verify before you pay