Identity & tool authority
Review user, tenant and service identities across retrieval, model calls and tool execution.
Permissions must be enforced by the application, not delegated to a system prompt.
Services / AI Safety & Reliability
AI security audits.Inspect the controls behind the confidence.
Understand how your AI application protects information, limits authority and handles untrusted content. We review architecture, code and configuration, verify selected boundaries and give your team an evidence-backed remediation plan.
Authorised assessment. Clear coverage. No security or compliance guarantees.
The business case
Know which controls exist—and which ones hold.
AI applications connect private information, probabilistic outputs and tools that can take action. Security depends on the boundaries around those capabilities, not only on whether the model refuses an unsafe request.
When an audit is useful
Before enterprise deployment, customer assurance review, expansion into sensitive workflows or a major change to tools and permissions. We can also examine an existing application after concerns about isolation, data exposure or unexplained actions.
What this service is
A scoped engineering assessment of selected AI and application-security controls, with evidence, findings and retesting. It is not independent certification, legal advice or an assurance that every vulnerability has been found.
Audit coverage
Six connected surfaces. One application.
Coverage is agreed against your architecture, reachable assets and available access. A public assistant, internal knowledge tool and autonomous workflow need different threat assumptions and verification depth.
Data & retrieval boundaries
Examine source access, indexing, memory, caching, logging and disclosure paths.
Authorised test records help verify that isolation works beyond the interface.
Untrusted inputs & outputs
Inspect how documents, messages, tool responses and generated content cross trust boundaries.
Content that informs an answer must not silently authorise an action.
Application & API controls
Review selected endpoints, session handling, validation, business rules and downstream integrations.
AI-specific controls cannot compensate for missing conventional application security.
Deployment & supply chain
Inspect secrets, dependencies, model artefacts, pipeline access and runtime configuration.
Coverage depends on authorised visibility; provider internals remain outside your application audit.
Detection & response
Review useful security signals, evidence access, incident routing and disablement procedures.
A configured alert is not proof that somebody can investigate and contain an incident.
Control verification
Follow the boundary. Preserve the evidence.
Connect identity, data and tool controls to observations your team can review. Inspection helps identify weak assumptions; targeted tests establish what selected controls actually enforce under the reviewed configuration.
More than an automated scan
Scanners and probe suites help discover candidates. We investigate context, prerequisites and reachable impact before treating an alert as a confirmed finding. Policy statements and settings are not substitutes for enforcement evidence.
Different from red teaming
An audit examines architecture, implementation and control evidence. Red teaming explores adversarial attack paths in greater depth. Where a control review exposes uncertainty, an additional focused assessment can provide more evidence.
Threat-informed scope
Audit the application, not an abstract model.
We begin with assets, users, data flows and consequential operations. That makes the review proportionate to the ways your system can actually expose information or exercise authority.
Architecture & trust map
Identify user interfaces, retrieval sources, models, memory, tools, service accounts and external integrations. Mark where information or authority crosses a boundary.
Threat assumptions
Agree realistic attacker access: an anonymous visitor, an authenticated user, a document contributor or a compromised integration. Prioritise reachable impact over generic threat lists.
Written authorisation
Name environments, accounts, endpoints, permitted methods and exclusions. Set traffic and spend limits, operational contacts and stop conditions before verification.
Evidence & limitations
Agree code-informed, configuration and runtime access. Inaccessible controls and third-party systems are explicit limitations, never assumed to be secure.
Access & authority
Trace who can read, decide and act.
An AI workflow may cross several identity contexts before it reaches a database or tool. We inspect how those contexts are preserved and whether delegation accidentally increases authority.
Server-side authorisation
Review access checks at sensitive reads and actions, including service-to-service calls. Test selected denied paths with controlled accounts, not only successful user journeys.
Tenant & document isolation
Inspect retrieval filters, index metadata, cached responses and conversation state. Check that revoked or restricted access cannot leak context into a model request.
Least-privilege tools
Review credential scope, typed arguments, allowlists and deterministic business rules. High-impact actions need controls outside model reasoning and tool descriptions.
Approval & delegation
Inspect approval binding to the exact action, reviewer identity, expiry and execution state. Verify that agent handoffs and background jobs do not bypass the original caller's permissions.
AI trust boundaries
Treat model inputs and outputs as untrusted.
We review the controls separating lower-trust content from instruction, authority and executable behaviour. Targeted verification complements inspection; deeper adaptive attack campaigns can be scoped as red teaming.
Prompt injection exposure
Trace documents, retrieved pages and tool responses into model context. Review whether attacker-controlled text can influence privileged tool requests or disclose protected information.
Output handling
Inspect schema validation, rendering, escaping and downstream consumption. Generated code, queries, URLs and parameters should not be executed solely because a model produced them.
Memory & shared context
Review persistent instructions, provenance and cross-session state. Check whether lower-trust contributors can poison shared memory or influence a more privileged agent.
Resource abuse controls
Inspect bounds on tool loops, conversation growth, retries, concurrency and spend. Any runtime verification is bounded by the agreed test limits, not an uncontrolled denial-of-service exercise.
Information handling
Follow sensitive data through the entire workflow.
Prompts are only one exposure path. Retrieval, traces, stored conversations, exports and support tooling may all carry sensitive information that needs deliberate access and retention controls.
Processing & provider paths
Map which information reaches each provider or service and review relevant configuration and processing terms with your privacy owners. Legal applicability is confirmed by qualified advisers.
Logs & audit evidence
Inspect redaction, access control, retention and export permissions. Security evidence should support investigation without unnecessarily duplicating private content.
Secrets & credentials
Review how secrets are stored, scoped, rotated and prevented from reaching browser bundles, prompts or logs. Use synthetic canaries rather than exposing live credentials in reports.
Lifecycle controls
Review deletion, retention, backup and access-revocation behaviour across indexes, caches and memory. Document gaps where downstream copies cannot be verified.
Application & infrastructure
Review the ordinary security beneath the AI.
We inspect selected code, API and deployment controls within the agreed boundary. A full web, mobile, network or infrastructure penetration test may require an additional specialist scope.
API & session controls
Review authentication, authorisation, input validation, session handling and relevant request protections. Prioritise paths that expose protected data or invoke privileged operations.
Dependencies & artefacts
Inspect dependency and container findings, model artefact provenance and loading behaviour. Triage scanner output against actual exposure rather than reporting every alert as exploitable.
Build & deployment access
Review pipeline permissions, protected configuration, infrastructure identities and environment separation. Assess whether a change can bypass agreed review or expose production secrets.
Runtime boundaries
Inspect sandboxing, filesystem access, egress restrictions and privileged execution where applicable. Code-executing agents need an explicit execution boundary, not a promise to behave.
Security operations
Can the team recognise and contain a problem?
Prevention and response need to connect. We review whether security-relevant activity can be investigated and whether the right people have a practical containment path.
Useful detection
Inspect signals for denied access, unusual tool use, repeated boundary violations and abnormal resource consumption. Distinguish actionable alerts from noisy model-output flags.
Investigation evidence
Review identity, request and action correlation with controlled evidence access. Preserve enough context to understand an incident without treating complete prompt capture as a default.
Containment options
Review tool disablement, credential revocation, session controls and rollback or forward recovery. Confirm the authority and operational access needed to use those options.
Ownership & reassessment
Name owners for findings and incident escalation. Changes to models, tools, permissions, data sources or providers can alter the attack surface and trigger another review.
Reporting & outputs
Useful to engineers. Clear to decision-makers.
A finding should explain what failed, why it matters and how your team can verify a fix. Reports distinguish verified vulnerabilities, control gaps, suspected issues and areas where evidence was insufficient.
Executive risk summary
The most important exposures, affected business workflows, assessment scope and limitations. Critical findings follow agreed notification procedures rather than waiting for the final report.
Technical findings register
Prerequisites, affected versions, supporting evidence, observed or potential impact, confidence, severity rationale and practical remediation. Suspected issues are separated from verified failures.
Control & coverage map
Controls inspected, selected checks performed, relevant framework mappings and exclusions. Not tested and insufficient evidence remain distinct from verified enforcement.
Retest & residual-risk record
Original findings, agreed fixes, verification results and unresolved work with accountable owners. Accepted risk is a documented decision, not a declaration that the system is safe.
Severity considers reachable impact, required access and exploitability. A provocative model response is not automatically a vulnerability; an unauthorised tool action can remain a finding even if the final answer appears harmless.
Tools & frameworks
A focused toolkit, not a security badge.
We choose tools for the agreed questions and your existing environment. Automated checks support manual investigation and reproducible evidence; no platform independently establishes that an AI application is secure.
Threat & control references
OWASP Top 10 for LLM ApplicationsOWASP ASVSMITRE ATLASNIST AI RMF
Organise relevant threat paths and application controls. Framework mapping is a coverage aid, not certification or proof of regulatory compliance.
Code & dependency review
SemgrepCodeQLTrivyGitleaks
Support targeted code, dependency, container and secret checks where supported. Manual review and exposure analysis are needed to validate and prioritise results.
Application verification
OWASP ZAPBurp SuitePlaywrightpytestVitest
Inspect authorised request paths and reproduce permission or workflow failures with controlled accounts and fixtures. Traffic generation follows the rules of engagement.
AI boundary checks
promptfooMicrosoft PyRITgarakSandbox tool fixtures
Use selected probes where they answer a specific control question. Automated judgements are reviewed against actual disclosure, authority and side effects.
Trace & evidence
OpenTelemetryLangfuseVersioned evidence register
Correlate model requests, identity and tool execution where visibility permits. Agree storage, access, redaction and retention before capturing evidence.
Deployment inspection
DockerKubernetesTerraformCloud IAMCI/CD configuration
Review the infrastructure and policies you actually use, including service permissions and execution boundaries. Tools are selected for operational fit, not imposed as a replacement stack.
Tools depend on supported capabilities, licensing, approved processing paths and authorisation. Taxonomies help organise coverage; they do not imply a complete assessment or regulatory compliance.
Delivery & outputs
From authorised scope to verified improvements.
The audit is collaborative and bounded. We discuss findings as they emerge, agree practical remediation priorities and keep unresolved risks visible through handover.
- 01
Scope & authorise
Agree assets, identities, environments, permitted methods, evidence handling and safety limits.
Output: Authorised audit scope and rules of engagement.
- 02
Map & inspect
Review architecture, code, configuration and existing evidence against prioritised threats and controls.
Output: Trust-boundary map and control-verification plan.
- 03
Verify & triage
Run agreed targeted checks, investigate suspected weaknesses and discuss material findings with your engineers.
Output: Evidence-backed findings, coverage notes and critical notifications.
- 04
Plan remediation
Explain failed boundaries, recommend proportionate fixes and agree ownership. Implementation is included only where explicitly scoped.
Output: Prioritised remediation backlog and acceptance requirements.
- 05
Retest & hand over
Verify agreed fixes and relevant variants. Record remaining exposure, limitations and reassessment triggers.
Output: Final audit report, retest record and controlled evidence handover.
A bounded first sprint
Start with a paid two-week sprint, one agreed goal and no required long-term commitment. A first scope can map an important workflow and verify priority controls. Comprehensive coverage and implementation may require additional work.
What your team brings
An application owner, written authorisation, architecture and integration details, relevant code and configuration, controlled accounts and a suitable test environment. We agree sensitive-evidence handling and operational safety before testing.
Remediation & handover
Strengthen the boundary, not just the prompt.
Useful fixes reduce reachable exposure and enforce authority in deterministic controls. Retesting checks the original failure, relevant variants and legitimate workflows so a defence does not simply make the product unusable.
Ownership stays with your team
Your code belongs to you from day one. Agreed configurations, test assets and documentation are handed over subject to data rights and third-party licences. Sensitive proof-of-concept material remains private under the agreed access and retention terms.
A reviewed snapshot, not permanent assurance
The report names reviewed versions, configuration, scope and limitations. Models, data, integrations and permissions can change the risk. Remediation, recurring audits and incident support are separately agreed, with named owners for open work.
Related services & guidance
Connect security findings to the next decision.
Use deeper adversarial testing, release assessment and technical guidance where your evidence shows a need.
Questions before assessment
The practical details.
How is a security audit different from AI red teaming?
An audit reviews architecture, code, configuration and evidence against agreed controls, with targeted verification. Red teaming explores adversarial attack paths more deeply, often through adaptive probes. They complement each other but have separate scopes and outputs.
Is this a certification or a compliance audit?
This is a scoped engineering security assessment, not independent certification, a legal opinion or statutory assurance. We can map findings to relevant controls and work with your advisers; a formal certification or regulatory audit requires its own qualified scope.
Can you audit a product built by another team?
Yes, with written authorisation and agreed access. Architecture, code, configuration, controlled accounts and trace visibility improve coverage. A black-box-only assessment has limitations that are stated in the report.
Do you need production access?
Not necessarily. Representative staging environments and controlled records are preferred for runtime checks. Production testing needs explicit approval, bounded methods, operational contacts and a stop procedure. Connected providers and third-party accounts are not automatically authorised targets.
Does the audit include a full penetration test?
Not by default. We agree which conventional application checks are included alongside AI-specific controls. Full web, mobile, network or infrastructure penetration testing may need an additional specialist engagement.
Will you fix the findings?
Your team can implement the recommendations, or we can agree a separate remediation scope. Retesting, code changes and ongoing support are clearly defined rather than assumed to be unlimited parts of the audit.
How long does an audit take?
It depends on the application, access, integrations and verification required. A paid two-week sprint can cover a bounded first scope without a required long-term commitment. Wider coverage and remediation may require additional work.
Will the report prove our AI is secure?
No assessment proves the absence of all vulnerabilities. Findings apply to the reviewed configuration, scope and observed evidence. We document exclusions, uncertainty and residual risk, with reassessment after material changes.
Start with the exposed boundary
Bring the application.
Let's examine what protects it.
Tell us what your AI can access, which actions it can take and where you need stronger evidence. We'll define a practical first audit scope.