For the security sign-off

Your agents will get injected.
With ZIFFER, they can’t act.

The agent holds no credential. A hijacked agent can propose anything and change nothing.

For the security sign-off

Your agents will get injected. With ZIFFER, they can’t act.

The agent holds no credential. A hijacked agent can propose anything and change nothing.

The rollout reaches your desk either way. The teams that ship agents control this exact 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 two risks about agent authority. The other two show none.

The rollout reaches your desk either way. The teams that ship agents control this exact 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 two risks about agent authority. The other two 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).

Assume the injection works.

Your agents read email, tickets and documents you don’t control. A sentence in them becomes an instruction.

The rule decides, not the model. A model fooled 2% of the time and one fooled every time meet the same rule.

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 action.
via a ticket it readsA poisoned ticket becomes a destructive write to production, authorized because the agent holds 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.

Assume the injection works.

Your agents read email, tickets and documents you don’t control. A sentence in them becomes an instruction.

The rule decides, not the model. A model fooled 2% of the time and one fooled every time meet the same rule.

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 action.
via a ticket it readsA poisoned ticket becomes a destructive write to production, authorized because the agent holds 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 sits between your agents and everything they touch.

We don’t filter prompts. The agent can be manipulated from 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. The proposal names an action from your catalog.

  • 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 you can show: there is no credential in the agent for an auditor to review

02 · The product

Your policy decides. Routine actions are granted in milliseconds. Actions nobody can take back are held for two named humans.

  • Granted when your rules grade the action LOW
  • Held for a quorum when your rules grade it HIGH. Each approver signs the exact bytes that will run. Silence is never consent.
  • Refused by default when no rule exists

03 · Enforcement

Only granted actions ever run. ZIFFER re-issues the action with its own credential, so the grant cannot be bypassed.

  • Your systems accept actions only from ZIFFER’s identity: one scoped credential per system, set up by one CloudFormation stack.
  • Your auditor can test it: send the same call around ZIFFER and watch it fail. That is a wall, not an alert.
  • What was granted is exactly what ran. ZIFFER recomputes it at execution and never trusts the message.

04 · Evidence

A signed receipt for everything that ran. The context the agent acted on is part of the record, and the ledger only appends.

  • Hybrid post-quantum signatures (Ed25519 + ML-DSA-65)
  • Not us, not your own admin: nobody can change a record once it is written
  • 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, not 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 the policy by a peer would only be trusting that peer.
  • Change control: epochs only increase, so a rollback to yesterday’s looser rules is refused

The platform

Agent authorization sits between your agents and everything they touch.

We don’t filter prompts. A manipulated agent still changes 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.

  • 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 you can show: there is no credential in the agent for an auditor to review

02 · The product

Your policy decides. Routine actions are granted in milliseconds. Actions nobody can take back are held for two named humans.

  • Granted when your rules grade the action LOW
  • Held for a quorum when your rules grade it HIGH. Each approver signs the exact bytes that will run. Silence is never consent.
  • Refused by default when no rule exists

03 · Enforcement

Only granted actions ever run. ZIFFER re-issues the action with its own credential, so the grant cannot be bypassed.

  • Your systems accept actions only from ZIFFER’s identity: one scoped credential per system, set up by one CloudFormation stack.
  • Your auditor can test it: send the same call around ZIFFER and watch it fail. That is a wall, not an alert.
  • What was granted is exactly what ran. ZIFFER recomputes it at execution and never trusts the message.

04 · Evidence

A signed receipt for everything that ran. The context the agent acted on is part of the record.

  • Hybrid post-quantum signatures (Ed25519 + ML-DSA-65)
  • Not us, not your own admin: nobody can change a record once it is written
  • Non-repudiation your auditor verifies with a public CLI, without production access

05 · Policy supply chain

Rules are signed offline. Publishing ends in a signing ceremony, not 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 the policy by a peer would only be trusting that peer.
  • 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 carry a published clause. Two hold by construction.

Zero credentials in the agent

Not vaulted, not brokered, not short-lived. The agent never touches a secret, so nothing can leak into a context window.

Proof of every action

Your agent platform shows what the agent saw. Every ZIFFER receipt proves what it was allowed to do: the action, the policy version, who approved, and the decision.

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, and each one signs the exact bytes that will run. The proposer cannot approve their own action.

Receipts, not logsAU-10 · AU-3

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

History nobody can rewriteAU-9(3)

The ledger only appends, anchored externally before an irreversible action releases.

The clause IDs are real. ZIFFER implements an open specification with machine-checked proofs and a public conformance suite. Every claim replays on your machine: ./tools/verify.sh --suites

The sign-off checklist

Six properties. Four carry a published clause. Two hold by construction.

Zero credentials in the agent

Not vaulted, not brokered, not short-lived. The agent never touches a secret, so nothing can leak into a context window.

Proof of every action

Your agent platform shows what the agent saw. Every ZIFFER receipt proves what it was allowed to do: the action, the policy version, who approved, and the decision.

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, and each one signs the exact bytes that will run. The proposer cannot approve their own action.

Receipts, not logsAU-10 · AU-3

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

History nobody can rewriteAU-9(3)

The ledger only appends, anchored externally before an irreversible action releases.

The clause IDs are real. ZIFFER implements an open specification with machine-checked proofs and a public conformance suite. Every claim replays on your machine: ./tools/verify.sh --suites

Pricing

Three arrangements. One question: who checks you?

Early access

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
On request

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
On request

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?

Early access

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
On request

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
On request

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 waiting for two humans kill agent speed?

Most of the day passes untouched. Only actions nobody can take back are held, so the holds are rare. A gate that fires on everything is approved on reflex, and OWASP lists that reflex as a threat of its own. Each hold reaches the approver with the facts already recorded: who proposed the action, what the agent had read, and what the action would do. 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. You can build the check loop in a weekend. The rest takes longer: machine-checked proofs, hybrid post-quantum signed receipts, an externally anchored ledger your own admin cannot rewrite, and a public conformance suite that proves 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. Through MCP, ZIFFER publishes your action catalog as the agent’s tools. One SDK call works too, and so does plain HTTPS. Each protected system gets one scoped credential that only ZIFFER can use. Onboarding starts within 48 hours. Your agent, model, framework and prompts don’t change.

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 waiting for two humans kill agent speed?

Most of the day passes untouched. Only actions nobody can take back are held, so the holds are rare. A gate that fires on everything is approved on reflex, and OWASP lists that reflex as a threat of its own. Each hold reaches the approver with the facts already recorded: who proposed the action, what the agent had read, and what the action would do. 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. You can build the check loop in a weekend. The rest takes longer: machine-checked proofs, hybrid post-quantum signed receipts, an externally anchored ledger your own admin cannot rewrite, and a public conformance suite that proves 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. Through MCP, ZIFFER publishes your action catalog as the agent’s tools. One SDK call works too, and so does plain HTTPS. Each protected system gets one scoped credential that only ZIFFER can use. Onboarding starts within 48 hours. Your agent, model, framework and prompts don’t change.

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 this rollout. In thirty minutes you get 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 this rollout. In thirty minutes you get the memo you would sign.

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