01 / Your app’s users
Who can see each record?
Start with access controls, public secrets and the checks to run before release.
User request→Permission
check→Private data
check→Private data
The developer library
Build fast.
Review the boundaries.
Practical security guides for the app you are building. Start with one question, follow the evidence, and use the free review templates.
Choose a learning path
02 / Your app’s AI tools
What can the agent do?
Separate untrusted content from trusted permissions, tokens and tool calls.
External text→Trusted
boundary→Tool action
boundary→Tool action
03 / Your review process
What does the evidence show?
Define scope, write useful findings and check that a proposed fix actually works.
Observation→Source
evidence→Retest
evidence→Retest
Useful files, ready to adapt
Keep a record
of what you checked.
Free Markdown and CSV worksheets. Use your own approved targets, test identities and evidence. Keep credentials and private customer data out.
A closer look
Guidance behind the checklist.
Three different security questions
AI application security can mean protecting an application that uses AI, reviewing code produced with AI assistance, or using AI to investigate application weaknesses. These overlap, but they are different questions. A generated web app still needs ordinary server-side authorization even when it contains no language model. An AI assistant that calls tools also needs controls around those tools and the data it retrieves.
This hub helps you choose a review based on your application’s actual behavior. It is educational guidance, not a scan result or certification. Use environments and records you own or are explicitly authorized to test.
| Situation | Security boundary | Start with |
|---|---|---|
| An app built with an AI coding assistant | Users, records, backend actions, and secrets | Release checklist and API authorization |
| An app that retrieves documents or calls AI tools | Document permissions, tool authority, and output destinations | Prompt injection and MCP controls |
| An AI agent used for security investigation | Authorized scope, tool limits, and reproducible evidence | Testing scope and finding quality |
Review an AI-built application before release
A working interface demonstrates that a user journey can succeed; it does not establish that forbidden actions fail. Write down which roles may read, change, export, or delete each important resource. Use controlled test accounts to check both allowed and denied behavior.
Begin with the release checklist, then follow the detailed guide for the boundary most relevant to your app. Keep a short evidence register containing the environment, expected rule, observed result, owner, and retest outcome. The downloadable review sheet below provides a starting structure.
Protect AI tools and retrieved content
Treat user messages, uploaded files, and retrieved pages as untrusted input. A model’s interpretation of that content must not grant access to another user’s records or authorize an outbound action. Enforce resource and action permissions in trusted code.
For MCP integrations, review the actual transport, authentication, consent, network destinations, and tool permissions. A connection that completes successfully has not automatically proved that a tenant boundary, token audience, or privileged tool is safe.
Evaluate agent-driven testing and findings
A useful investigation separates an observed issue from an unverified possibility. It should explain the affected operation, prerequisites, sanitized evidence, impact, and intended correction. Automated scanners, code review, dependency checks, and agents can contribute different kinds of evidence.
Before active assessment, establish authorization, scope, synthetic data, rate limits, and stop conditions. After remediation, check the original failure and a legitimate user journey. A merged patch and a verified deployed fix are different states.
Reusable assessment and release templates
Download a scope worksheet before an authorized assessment, or a release-review register for a small application. Replace the placeholders with your own approved targets, permission rules, test identities, and owners. They are review aids, not authorization from WarHoundAI or proof that an application is secure.
The release sheet contains example review categories rather than a promised coverage list. Add checks for your own architecture and data. Keep live passwords, tokens, and customer records out of shared worksheets.
Primary references and further reading
Technical guidance changes as protocols and applications evolve. Consult the linked primary documentation for implementation details and review the version that applies to your deployment. Our articles identify their sources and use illustrative examples rather than claiming undisclosed production tests.
Where WarHound AI fits
These guides are free to use on their own. Mini Hound is available now for bounded public-source reviews. BloodHound’s broader assessments and developer integrations remain in development.
Educational examples are not scan results, certifications or evidence of product coverage.
The next step
Want help reading public code?
Mini Hound can explain possible issues and the source behind them.