For security reviewers
Don't take the vendor's word. Run the check yourself.
A vendor's AI application wants access to your environment: an agent, plus every tool, identity and data flow around it. Their questionnaire moves the risk onto your desk; a signed report does not. Open it, verify it offline against their public key, read the findings in your frameworks.
An agent is not another SaaS integration.
It holds credentials and acts on its own, with no human at each step. Three things change what your review has to confirm.
It acts, it doesn't just answer
The blast radius is everything it can reach
If the agent holds more access than the job needs, often on one shared key, every scope is exposed the moment it is compromised or redirected.
ASR-1 · least privilege
A log you can edit is not evidence
The trail has to survive an investigation
When something goes wrong, you reconstruct it from the activity log. A log that can be changed after the fact cannot anchor an incident.
ASR-2 · audit trail
Confidence is not a control
A questionnaire is the vendor grading itself
Self-attested answers tell you what the vendor believes. You cannot test a single line, so the burden of proof lands on your team.
ASR-6 · evidence
Your situation, what kolm does, the proof to check.
One line of sight from a vendor asking for access to a verdict you ran yourself. Each step carries the concrete output it produces.
An agent wants in
A vendor agent asks for access and hands you a questionnaire you cannot test.
0 linesyou can verifyTurns claims into a signed object
One signed object carries the findings, the scope, and the issuer key inside.
1 objectkey travels insideYou run the check
Verify the signature in your browser and match the key to your pinned keyring.
VALIDoffline, no accountProof you can check, not answers you have to trust.
Require an artifact that carries its own proof. The question stops being whether you believe the vendor and becomes whether the signature checks out.
What you get today
A questionnaire
Self-attested answers in a spreadsheet, stale the moment it is signed, impossible to compare across vendors. Untestable by design.
What to require instead
A signed evidence report
One canonical object, signed with Ed25519, the issuer's public key inside it. You check the signature yourself and trace each finding to a control.
- A signed report, not a slide or a spreadsheet
- The issuer's public key inside it, so you verify provenance, not just integrity
- Findings mapped to the frameworks you already enforce
- The scope statement carried inside the signed object, so you read exactly what was tested
Two checks. Your browser. No server.
Both run on WebCrypto (the browser's built-in crypto)WebCrypto is the cryptography built into every modern browser. The signature check runs there locally, so no code or data leaves your machine. in your own browser. One confirms the bytes are intact, the other confirms who signed them by matching the key against your pinned keyring (the issuer keys you trust)A pinned keyring is the short list of issuer public keys your team has decided to trust. A report signed by a key outside that list fails the issuer check even if its signature is valid.. kolm is never in the path.
Tier 1 · signature
Edit one field, the seal breaks
The signature covers the canonical bytes. Change a finding or inflate a score and the match fails, in front of you. This is integrity.
Tier 2 · issuer
A rogue key clears Tier 1, fails Tier 2
The signing key is checked against the keyring you pinned. A forged key can sign a clean report; it is still not the issuer you expect.
Offline · no account
Nothing for anyone to fake
No upload, no portal, no kolm server in the trust path. The public key travels inside the report, so the check needs nothing else.
Scope is contractual. Permission posture, redaction and audit-trail integrity are assessed. Injection is tested and reported, not warranted.
Issuer key fa562154f99c95f4... · append-only transparency log · inspect the verifier source · the threat model behind the check
Every finding lands in a control you already enforce.
Eight agent-security controls, mapped to the six frameworks your review group already cites. No translating the vendor's terms into yours.
| Control | What it checks | Maps to |
|---|---|---|
| ASR-1 Least privilege | Scopes the agent holds versus the scopes it uses | SOC 2 CC6 · OWASP ASI03 · NIST MANAGE-1 |
| ASR-2 Audit trail | Append-only, hash-chained, retained activity log | EU AI Act Art.12 · SOC 2 CC7 |
| ASR-3 Data egress | Destinations, approved sub-processors, redaction | OWASP LLM02 · EU AI Act Art.10 |
| ASR-4 Injection | Instruction hijack, indirect injection, guardrail bypass | OWASP LLM01 · MITRE ATLAS AML.T0051 |
| ASR-5 Provenance | Model and dependency provenance | ISO 42001 A.10 · OWASP ASI04 |
| ASR-6 Evidence | Signed, logged, offline-verifiable report | SOC 2 CC7 · CSA AICM A&A-02 |
| ASR-7 Memory and retrieval integrity | Retrieval sources enumerated and trusted; memory writes integrity-linked | OWASP ASI06 · OWASP LLM08 · MITRE ATLAS AML.T0070 |
| ASR-8 Multi-agent delegation | Handoffs attributable; sub-agents attenuated to a subset of authority | OWASP ASI03 · OWASP ASI07 · CSA AICM IAM-16 |
The mapping travels inside the signed object. kolm maps findings to standards; it never certifies compliance. The full control catalog
Require evidence, not assurances.
Make "show me, don't tell me" the default for every agent entering your environment. Open a signed report and check it yourself.
Caveats: Scope is contractual. Permission posture, redaction and audit-trail integrity are assessed. Injection is tested and reported, not warranted.