You have built an agent feature. Your product development contact loves it. Then procurement sends the security questionnaire.
Question 26 asks how you prevent prompt injection. Question 27 wants to know about model output validation. Question 28 asks whether you log every instruction sent to the model and whether those logs are tamper-proof.
Your conventional SAST tooling flags nothing. The questions remain unanswered. The deal stalls.
What enterprise buyers actually ask
The AI sections of security questionnaires fall into three categories.
Input validation and injection prevention. Can an attacker embed instructions in user input that override your system prompt? How do you sanitise file uploads, URLs and structured data before sending them to a model? What happens when a user submits invisible Unicode or homoglyph attacks?
Output controls and guardrails. Do you validate model responses before acting on them? What prevents the model from returning executable code, credentials or personally identifiable information? Can you demonstrate refusal handling?
Audit and observability. Do you log every model call with the full prompt, response, timestamp and user? Can you produce an exportable audit trail? Do you track cost, latency and refusal rates per feature and per user?
These are reasonable questions. They reflect the OWASP Top 10 for Agentic Applications, the OWASP LLM Top 10 and increasingly the EU AI Act's transparency requirements under Article 50.
Why your existing tooling cannot answer them
Static analysis tools built for traditional web applications do not understand agent-specific risks.
They flag SQL injection in database queries. They catch XSS in HTML rendering. They do not flag a system prompt that lacks delimiter tokens, a user input concatenated directly into a prompt string, or a model response written to disk without validation.
Dynamic application security testing tools can fuzz HTTP endpoints. They cannot craft adversarial prompts designed to exfiltrate instructions, override refusal behaviour or smuggle invisible characters through a tokeniser.
Dependency scanners check for known CVEs in npm packages. They do not check whether your code validates structured output from a model before calling eval() or writing to a database.
The gap is specific and material. Procurement knows it.
What you can put in writing
Start with source code evidence.
If you use delimiters around user input in your prompts, you can point to the line. If you validate model output with a schema before acting on it, you can show the validation function. If you log every model call to an append-only store, you can demonstrate the logging middleware.
This is not a penetration test. It is not a compliance certification. It is evidence that you have considered the risk and implemented controls.
ASIScan is a static analysis scanner built for this purpose. It audits agent codebases against the OWASP Top 10 for Agentic Applications, the OWASP LLM Top 10 and EU AI Act Article 50. It detects eighteen categories of issue, including invisible instruction smuggling, missing output validation and unlogged model calls.
The scanner is free and MIT licensed. Run npx asiscan . in your repository. It outputs to terminal, markdown, JSON or SARIF 2.1.0. There is a GitHub Action that gates pull requests on scan results.
It runs offline with no telemetry. Your code does not leave your machine.
Measured precision is roughly 75 per cent, reported on the tool's own site. It reads source code only — not runtime behaviour, IAM policies or model output. It is regex-based rather than AST-based. It is explicitly not a certification, conformity assessment or legal advice.
Carry those limitations honestly when you present results to procurement.
When not to spend money on this
If you are not selling into enterprise accounts, do not optimise for enterprise questionnaires.
If your product does not use agents — if it is a prompt wrapper, a fine-tuned classifier or a retrieval pipeline with no model-driven control flow — the agent-specific sections do not apply. Answer them as not applicable and move on.
If procurement is asking for ISO 27001 certification, SOC 2 Type II attestation or FedRAMP authorisation, a source code scanner will not satisfy the requirement. Those are organisational security programmes that take months and cost tens of thousands of dollars. A static analysis tool is useful preparation. It is not a substitute.
Run the free scanner first. If it flags nothing, you may already meet the threshold. If it flags issues you can fix in a few hours, fix them and re-scan. If it flags architectural gaps that would require a rewrite, decide whether the deal justifies the work.
Do not buy a paid security assessment until you know what the free scan reveals.
Building audit trails into custom applications
If you are building a custom agent application rather than integrating a third-party product, you can design audit and observability in from the start.
Every model call should pass through a single logging layer. Log the full prompt, the full response, the model name, token counts, latency and cost. Tag each call with the user identifier and the feature that triggered it.
Store logs in an append-only format. S3 with object lock, a write-once database table or a dedicated audit log service all work. The requirement is tamper-evidence, not cryptographic proof.
Expose cost attribution per user and per feature. Expose refusal and escalation rates. Set spend caps and alerts. Make the audit trail exportable as CSV or JSON.
This is exactly what we build into custom AI applications. An AI activity layer that logs every model call. Cost attribution. Refusal tracking. Exportable audit trails.
These features cost nothing extra to include during initial development. They are expensive to retrofit later. If you know enterprise deals are in your pipeline, build them now.
What this looks like in practice
Procurement sends the questionnaire. You run ASIScan and attach the markdown report. You reference specific lines in your repository where delimiters, output validation and logging are implemented. You include a screenshot of your audit log interface showing timestamped model calls with full prompts and responses.
You state plainly that the scanner is regex-based, reads source code only and is not a certification. You state plainly what it does and does not cover.
You answer the questions you can answer with evidence. You mark the others as not applicable or not currently implemented, with a timeline if the deal justifies building the control.
This is enough to move past question 26.
Where to start
If you have an agent codebase, run the free scanner today. It takes two minutes and costs nothing.
If you are building a custom application and expect enterprise buyers, talk to us about workflow automation with audit and observability built in from day one. One conversation, no obligation.
Reach us at info@easeaiworks.com or review our pricing and AI grant options for Ontario businesses.
Ease AI