ZIFFER is an authorization layer for AI agents. The agent holds no credential on your systems; every action is a proposal, your policy grants it, holds it for named humans, or refuses it. Every outcome leaves a signed decision record, and only an allowed action also gets a signed receipt.
The category
Three layers in your stack already decide things, and none of them decides this one. Detection says whether something is happening. Orchestration says which playbook runs next. Identity says who may connect to what. Not one of them says whether this action, on this target, was entitled to run right now. Until now that answer was a person at a console.
ZIFFER is that layer. It sits where a proposed action passes, grades it against a signed policy you publish, and signs a receipt only for what the policy grants. Your own code runs the action, and only after it verified that receipt.
The layer is needed because the agent's reading cannot be made safe. OWASP's own entry on prompt injection says it is unclear whether fool-proof prevention exists, and its entry on excessive agency is the other half: an agent holding functionality, permission or autonomy beyond its task. A filter reduces the first. Only authority bounds the second.
What ZIFFER is not
ZIFFER decides whether a proposed action runs. Read that as a limit, not a slogan.
- It does not detect anything, it does not make triage more accurate, and it does not replace your SIEM or SOAR.
- It never inspects text. It grades a proposed action, so a fluent, persuasive instruction that no rule covers is refused for the same reason a clumsy one is.
- It does not hold your data or your credentials. The credential stays in your tool, and your code will not use it without a receipt it verified itself.
- It covers an agent only where that agent holds no credential of its own. An agent with an API key in a config file is outside the wall until that key is revoked.
- It does not replace your analysts. They keep their consoles and their own accounts.
Three stages
Investigate. Every tool call is a proposal. Actions with a fixed shape are catalog entries, and the agent cannot express one outside the catalog.
Respond. Your signed policy grades every proposal. Reversible and in scope: granted. Irreversible or high impact: held for the quorum your signed policy sets: named approvers, each signing the exact bytes that will run. No rule: refused.
Prove. Every outcome, refusals too, leaves a signed decision record: the action, the policy version, who approved. Only an allowed action also gets a signed receipt, which your code verifies before it runs. A refused proposal or an expired hold leaves the record and no receipt. The record is what your auditor asks for.
The pages in this section
Two groups, in the order meta.json holds them. Each page answers one question in full before ZIFFER is named.
Prompt injection.
- Prompt injection: the defender's playbook: what it is, how to detect it, and every mitigation layer with its effect and its limit.
- Indirect prompt injection: the attacker's instructions arrive in data the agent fetches, so no attacker touches the prompt.
- Prompt injection defences and their limits: one row per layer: measured effect, known bypass, source.
- Prompt injection in AI agents: in an agent an injection is not a bad answer, it is an action taken with the agent's own authority.
- Prompt injection in the SOC: a SOC agent reads attacker-controlled text by definition: the alert, the ticket, the sample.
- Containing a successful injection: what the injected agent can still cause after every filter has failed.
- The OWASP Top 10 for LLM applications, read as an agent threat model: two entries decide whether an agent is safe to give authority to.
- LLM guardrail frameworks, and what none of them can do: the open-source classifiers, their licences, and the limit they share.
- Protect AI agents from indirect prompt injection: one channel per section, with the realistic control and its limit.
- Adversarial robustness evaluation for LLMs: evaluation measures the filter; receipts measure the outcome.
Concepts.
- Agent authorization: whether a specific proposed action may run, separately from whether the agent may connect.
- AI agent credentials: a credential converts the agent's output into an effect; holding one is authority, not identity.
- Human-in-the-loop for AI agents: a gate an action cannot pass without a person's decision recorded against it.
- Dual authorization for AI agents: two distinct identities confirm one action; NIST AC-3(2) calls it two-person control.
- The AI agent audit trail: evidence a party who was not there, and does not trust you, can check.
- Agentic SOC security: an agentic SOC is one where AI agents take response actions, not only triage them.
- Excessive agency: functionality, permission or autonomy an agent holds beyond its task.
- Agent controls mapped to DORA, the AI Act, NIS2 and ISO 27001: per clause: what a mechanism satisfies, supports, and does not address.
The pages above are being written. A link that answers with a 404 today is one whose page has not landed yet; the order is the one content/learn/meta.json holds, and it is where each will appear.