The scanner: read the report

Who this is for: whoever reads what the scan wrote, the engineer who ran it or the person it was forwarded to.

What you end up with: for each part of the report, the question it answers and how far to trust the answer, and what to do once you have read it.

Everything in the report is a reading of files, not a test of a running system. Every tool is classified from its own name and description, the grade depends on that classification, and the policy is a draft. What the scan reads and does not lists what the scan cannot see; read it before you rely on a clean result.

The examples below come from an invented booking application with three tools, getBooking, addCharge and cancelBooking. They are an example, not a real customer's report.

1. Three places to read the same result

• The screen. One summary that fits a terminal, ending with what to do next. --full prints everything after it.
• ziffer-scan-report.html, written with --report. One page to open in a browser and to forward. It loads nothing from the internet: fonts and styles are inside the file, and the page forbids itself from fetching anything else. Credentials are shown as [redacted] and paths under your home folder start with ~. The machine is named by its host name only.
• ziffer-scan.json, the same result for a program. It is the document --json prints.

Running the scan says when each file is written.

2. What the report answers

The report is read by what you need to know, not from top to bottom. These are the questions it answers, and what to keep in mind for each.

What can a model in my application do today? How many tools your code gives a model, in how many files, and through which framework. Then the tools that cannot be undone, by their own name or description, and the ones that only read. For the example application:

A model in booking-app can call 3 live tools. 2 cannot be undone, by their own
name or description. 1 only reads.

What would change with ZIFFER? For each tool, what ZIFFER would do with a call to it under the draft policy. The four outcomes are in section 4.

Where do I put the ZIFFER call? The one place in your code every tool call passes through, when the scan found one. When it did not, the report says so and names the top of each tool's own function instead, starting with one tool and its file and line. With --report, the code to paste is on the page. That code waits for the signed receipt and checks it in your own process, against your trust anchor, your suite floor and, for an action someone approved, your approver registry, before the tool runs; a receipt that does not check out stops the call. Its first lines name each environment variable it reads and where the value comes from.

Is the scan's reading right? Each tool with the reason it was classified the way it was, such as name says "cancel". A reason is a reading of words. Confirm each one: a tool named cancelBooking may in fact be reversible in your application, and one with a harmless name may not be.

What did the scan not read? Tool sets built at run time, files it could not resolve, languages it does not parse, skills whose loader it did not see. Each is one line with a count and, where it has one, a file and line. A tool that appears in none of the lists is not proof that it does not exist.

Which skills and instruction files does my application or my coding assistant load? Each one found, who loads it, what it declares and what it does, such as running a shell command or reaching the network. Text that reads like an instruction to an AI agent is a finding.

What can the AI tools on my machine reach? When the installed half ran: every tool server your AI tools are configured to start, the tools each one listed, and the pairs where one tool reads something an outsider can write and another sends data out. Also what the scan could not see: servers that did not start in time, remote servers, and the AI tools it cannot read.

What would an injected instruction do? The replay: eight instructions of the kind a prompt-injected AI agent might follow, each shown without ZIFFER and under the draft policy. Its receipts are signed by a key made for that run and thrown away, and the report labels them a demonstration, not evidence.

Which OWASP entry is this about? The report cites one entry of the OWASP Top 10 for LLM Applications: Excessive Agency. Beside the name it prints the identifier the list's current edition gives that entry, with the edition and its publication date, because the numbering has changed between editions. It says which two of that entry's nine prevention strategies a check before each tool call answers, and that the other seven remain your own work.

3. The grade: one letter today, and the letter you can reach

The grade is the share of your application's tools that do something that cannot be undone, or that the ZIFFER engine refused because the draft has no rule for them:

The report shows one letter: the grade today. Some tools change data and say nothing, in their name or description, about whether that can be undone. The engine treats a tool like that as one that cannot be undone, because unknown is never treated as safe. So those tools count against the grade today.

Under the letter, one sentence says which grade you can reach and how. Suppose the invented booking application had 12 tools: addCharge and cancelBooking say they cannot be undone, and three others change a booking without saying either way. The report would read:

D today. 3 tools change data and do not say whether that can be undone, so they count as not undoable. If all 3 can be undone, the grade is C.

To reach the better grade, say for each of those tools whether it can be undone. You record that in the draft policy's reversibility.json. A tool you mark as one that cannot be undone keeps counting, as it should.

When no tool is in that position, the report shows one letter and no second sentence.

Tools whose description says they are stubs are not counted, and the report says how many were left out. If the scan could not resolve some of your imports, the grade is marked provisional, and the report says why in words: tools defined in those files may be missing.

4. What each outcome means

Each tool is shown with what ZIFFER would do with a call to it under the draft policy. That is the draft's answer, not a decision about your business: you change it by reviewing the draft.

• Held for a person. The call waits until a named person approves it, then runs. Nothing happens before that. This is what happens to a call graded high risk.
• Runs after a notice. The call runs without an approval, and the people the policy names are told first. It lets you detect a bad call; it does not prevent one.
• Runs, recorded. The call runs, and ZIFFER records it with a signed receipt.
• Refused: no rule. The draft has no rule for the tool, so the engine will not let it run. An unknown tool is never treated as safe.

The page carries a short legend for these words and for the risk levels and tiers it uses.

5. The draft policy: what it is and what it is not

The scan writes a draft policy, ziffer-policy/, from what it found. It is a real ZIFFER policy folder, and the grading in the report comes from ZIFFER's engine reading it.

It is a draft to review, not a policy to deploy. It is signed by a key made for that one run and thrown away before the run ends. No deployed policy names that key, so nothing the draft signs is evidence for anyone else. Its classifications are read from tool names and descriptions. It still carries placeholders for things only you can decide: who approves, who is told first, and the key your organisation signs with. The report lists the draft as a checklist.

A tool the scan could not classify gets no rule, so the draft refuses it. It is never guessed at.

6. The JSON

ziffer-scan.json holds the same result as the page, with the same redaction. Its main parts, by what they answer:

With --report, the --json output also says where the report and the archive were written.

7. What to do next

1. Confirm the classifications, and change the draft where the scan read your tools wrongly.
2. Name the people who approve and the people told first.
3. Ask for the review on the page below, and attach the archive --report wrote, ziffer-review.tar.gz, to the email that page sends you.

https://ziffer.io/review

The policy, file by file explains every file in the policy folder, line by line.