You deployed AI. Nobody has looked at what it exposed.
We audit the three layers where risk lives — the AI layer, the classical application and the infrastructure that supports them — in a single engagement, and redesign the parts where a known attack is still possible.
No access to production · Read-only access to the code · Report with file-and-line evidence
The serious failure isn't in the model. It's where the model touches the rest of the system.
AI applications almost never fail because of the model itself. They fail when its output enters a classical layer that wasn't built to receive it.
AI widens the attack surface
An agent that calls tools, a chatbot over your documents or a RAG pipeline all add inputs nobody controls. A document a client uploads can carry hidden instructions inside the text — that's indirect prompt injection: the attacker doesn't write to you, they write to the file your system is about to read.
The damage still happens in classical controls
An injected instruction only does damage if there's a broad authorization, a secret in the repository, an unvalidated query or an uncontrolled endpoint on the other side. The AI layer opens the door; the classical layer is where something gets lost.
Nobody looks at all three layers at once
The security team reviews the classical stack and doesn't know how the agents behave. Whoever built the AI knows the model and doesn't audit sessions, permissions or service identities. And the infrastructure is run by a third party who doesn't know what reaches the agent. The failure lives in the seam, which belongs to no one.
Four concrete moments
If you're in any of these, the diagnostic is useful now, not in six months. If you're in none of them, you probably don't need it yet.
You're about to give an agent access to tools that do something
Writing to a database, sending emails, calling a third-party API, moving money. The day an agent moves from answering to acting, the risk changes in nature.
A working pilot is about to move to production
What was built to prove the idea worked was rarely built to withstand someone trying to break it. It's the cheapest moment to fix it.
A client sent you a security questionnaire with questions about AI
More and more RFPs ask how you control model behavior and what permissions your agents have. Without a documented answer, the deal stalls.
You're about to index documents you don't control
Files your clients upload, incoming email, external pages. From the moment they enter the RAG pipeline, someone outside is writing into your system.
First we see what's there. Then we harden it.
Two consecutive lines of work. One provider and one point of contact for both.
Diagnostic
Security analysis of an application already in production, covering three layers in a single engagement.
- AI layer. Direct and indirect prompt injection; authorization of agents and the tools they call; MCP security; model output that reaches the interface or the database unvalidated; RAG pipelines that index untrusted documents from your clients.
- Classical layer. Authentication and authorization, secrets in the repository, session management, endpoint surface, input validation, logging and traceability.
- Infrastructure layer. Cloud and deployment configuration, identities and permissions of machines and services, network segmentation and public exposure, containers and base images, secrets and key management, CI/CD chain and dependencies, backups and log retention.
- The seam. The complete path from an untrusted input to an action with an external effect — which is where the serious failure is born.
Contracted separately. Requires no prior work.
Hardening
Designing and implementing defenses so known attacks stop being possible by construction, not by filtering.
- Separation of plan and data. The component that decides what to do never sees untrusted content; the one that processes untrusted content can't execute actions.
- Deterministic mediation. No action with an external effect — sending, writing, paying, publishing, calling an API — runs without passing through a control point that isn't a model.
- Typed output validation. Checked against a schema or a closed catalog before it reaches the database, the interface or another system.
- Real least privilege. Permissions per action and per resource for agents and tools, instead of one broad, shared credential.
- RAG pipeline hardening. Isolation of untrusted documents, safe rendering of responses, control over what can be cited and where data can be sent.
- Adversarial testing and traces. Before going to production, plus logging that lets you answer later if something was exploited.
Requires Line 1 or an equivalent audit to have been done first.
An input filter can be beaten; structural containment can't. A classifier that decides whether a piece of text is malicious is just another model, and it can be worked around. A control point that only allows three actions on specific resources doesn't depend on having interpreted intent correctly. The defense doesn't live inside the model — it lives around it.
Where the attack path gets cut
Untrusted content is always going to reach the model. What the design decides is what it can do with what it read.
The model's output goes straight to the database, the browser or the tool. Whoever controls the input document controls the action. It's the default path for almost any integration built quickly, and the first thing we review.
The injected instruction still reaches the model, but it dies at the control point: what doesn't fit the schema doesn't pass, and what isn't permitted for that user and that resource doesn't execute. The attack isn't eliminated — its effect is.
Does your application have that control point? If you can't answer with certainty, that's exactly the question the diagnostic starts with.
Talk to whoever does the workWhat can happen if a gap goes uncovered
No alarmism and no invented cases: this is how, in attack theory, a single missing control turns into an incident. Each link is a point where hardening work can cut the chain.
- Step 1 · Input
The attacker writes where you aren't looking
They don't attack you directly: they prepare a document, an email or a page your system is going to read, with instructions aimed at the model.
- Step 2 · Confusion
The model doesn't distinguish data from instructions
It processes that content alongside its own instructions. Without separation between the component that decides and the one that reads, the foreign instruction enters the plan.
- Step 3 · Privilege
It acts with the system's permissions, not the attacker's
The agent executes with the credential it was given. If it's broad and shared, it reaches data and functions the attacker could never have requested on their own.
- Step 4 · Movement
It jumps to the classical layer or the infrastructure
Unvalidated output reaches a query, a browser or an API. From there, an over-permissioned service identity or an unsegmented network widens the reach.
- Step 5 · Impact
And there's no record of how it happened
Without traces of the agent's reasoning and actions, the later investigation can't reconstruct what was done, with what data, or since when.
A data leak you can't scope
The expensive part of an incident is rarely the data itself: it's not being able to say how many records, whose, and in what time window. Without traceability you have to notify assuming the worst case.
Actions executed in your name
An agent with write, send or payment permissions that acts on a foreign instruction produces real facts: emails sent, records altered, operations launched. Undoing them is manual work.
A regulatory obligation kicks in
A personal data breach triggers notification deadlines to the supervisory authority under GDPR, with a sanctions regime reaching up to 4% of global annual turnover. If you operate in sectors covered by NIS2, additional notification obligations apply.
Contracts and clients start asking
More and more RFPs and vendor questionnaires explicitly ask how the behavior of AI systems is controlled. Without a documented answer, the sale slows down even if no incident occurred.
Why one control is enough to cut the chain
The chain above is sequential: each step needs the previous one to have gone through. A permission scoped by action and resource cuts step 3 even if 1 and 2 already happened; output validated against a closed schema cuts step 4. That's why the priority isn't preventing the attacker from writing — which is impossible — but making sure no link in the chain is ever complete.
Why a filter doesn't count as a control
A classifier that decides whether a piece of text is malicious is just another probabilistic model: it's right almost always and fails on the one case someone built to make it fail. A deterministic control point doesn't interpret intent — it only allows a closed set of actions on specific resources. The first reduces noise; only the second bounds the worst case.
Four steps, without touching production
Scope and access
We define which applications and repositories are in scope. Read-only access to the code. No deployments, no tests against your live environment.
Static analysis
Review of the code and the declared infrastructure: data flows from every untrusted input, agent and tool permissions, classical controls, service identities, network exposure and deployment configuration.
Report
Findings classified by severity, each with file-and-line evidence, described impact and concrete remediation.
Review session
We walk through the report with your development team, prioritize together and resolve questions about each proposed remediation.
Implementation — only if hardening is contracted
Defenses are agreed on with your team and implemented on your code, within your workflow. Every remediated point is covered by a test that fails if the protection is ever removed.
A document your team can act on
Diagnostic
- PDF report with a datasheet per finding
- Risk matrix by severity and impact
- Executive summary kept separate from the technical detail, so leadership and development each read what's theirs
Hardening
- Everything above, plus the implemented controls
- For each control, the test that verifies it and fails if someone removes it in a future change
- Documentation of the design decisions, so the team can maintain them without us
What you walk away with, in terms of your business
You can ship what's stuck
The integration nobody will sign off on because nobody knows what it exposes stops being blocked: you know what risk it carries, what got contained, and what's consciously accepted.
You can answer the big client's questionnaire
With a document, not a call. Questions about model control, agent permissions and traceability have a written answer with evidence behind it.
You can tell the board what you exposed
The executive summary is kept separate from the technical detail for exactly this: leadership reads risk and decision, development reads file and line.
How we classify severity
| Severity | Criteria | Example of the finding type |
|---|---|---|
| Critical | An action with an external effect reachable from an input a third party controls, with no intermediate control. | An uploaded document gets the agent to invoke a write or send tool. |
| High | Access to data or functions outside the user's scope, or reachable control under certain conditions. | A broad credential shared across tools; model output that reaches a query unvalidated. |
| Medium | A weakness that doesn't grant access by itself, but lowers the cost of chaining an attack. | Insufficient logging to reconstruct what an agent did; unsanitized rendering of responses. |
| Low | A deviation from good practice with no exploitation path identified within this scope. | Deployment configuration more permissive than necessary on an internal service. |
Public frameworks, original research, no filler
The review is grounded in recognized reference catalogs, so the report can be checked against an external standard instead of our own opinion.
Original research
A doctoral thesis on multi-agent system security and structural containment of model output: how to make verification a property of the architecture instead of a filter bolted on at the end. It's the same criteria we apply to hardening.
One point of contact
The same people who audit are the ones who implement afterward. There's no handoff between a team that finds issues and another that fixes them, and no report that needs translating for someone else to execute.
A new line of work, and we say so
This service is a new line of work within XGen-AI Smart Documents: we don't have publishable audit case studies yet, and we're not going to fill this page with logos or invented testimonials. What we do bring is a company that has spent years building AI applications in production, and doctoral-level research on the exact problem this service addresses.
For whoever comes in now, that has a concrete trade-off: scope agreed in writing before starting, direct access to whoever does the work with no sales layers in between, and early-engagement terms.
Scope tiers
One application
A product with one AI surface — an assistant, a document chatbot or an agent — with its classical layer and the infrastructure it runs on.
Priced by scope
Multiple applications or a platform
A set of services that share authentication, data or tools, including the relationships between them.
Priced by scope
Diagnostic and hardening
A full audit plus the design and implementation of defenses, with verification of what was remediated.
Priced by scope
What we usually get asked
The questions that always come up in the first conversation, answered here so a call isn't needed just to find them out.
Are you going to touch our production environment?
No. The analysis is static, over the code and configuration, with read-only access. We don't deploy, we don't send traffic against your services, and we don't run intrusion tests against the live environment. If at some point a finding needs to be validated at runtime, it's done on a test environment and only with your express written authorization.
How is our code protected?
A confidentiality agreement is signed before we receive any access. The code is worked on in encrypted environments, never copied to third-party services, and never used to train any model. When the engagement closes we delete the copies and confirm it to you in writing. If you have your own agreement template, we work under yours.
How long does it take, and what do you need from us?
Duration depends on scope and is agreed in writing before starting. On your side, three things are needed: read access to the repository, a one-hour conversation with whoever built the AI part to understand what each agent does, and a technical point of contact available for questions.
What if you don't find anything critical?
That's a valid outcome and it's still delivered, with the reviewed scope documented: what was looked at, under what criteria, and what's out of scope. A report that says where there's no problem, and backs it with evidence, is what you need to answer a client or an auditor who asks. We don't inflate severities to make the report look denser.
We already have an annual pentest. Does this replace it?
No, it complements it. A classical pentest looks for exploitable flaws from the outside at a specific point in time; this reviews how the application is built, including the AI layer that most pentests don't cover because an agent's behavior isn't tested with the same tools. Usually, both coexist.
What happens when the code changes?
A report goes stale. That's why hardening leaves tests behind: every implemented control has a test that fails if someone removes it in a future change, so the protection holds without depending on anyone remembering the report. For diagnostic-only engagements, a follow-up review of the remediated points can be agreed on.
Can you eliminate prompt injection?
No, and be wary of anyone who promises that. Today there's no model-level defense that eliminates it, because the model can't reliably distinguish data from an instruction. What can be done — and what we do — is reduce the surface it enters through, contain the impact when it does, and make sure dangerous actions never depend on the model having interpreted things correctly.
Start with the conversation, not the project
One line about your application is enough to say whether the diagnostic would add something, and what scope it would have.
A free technical call, thirty minutes
A call with whoever would do the work, not a salesperson. You tell us what you've built, and you walk away with three things, whether or not you intend to hire us:
- What untrusted inputs reach your system today, and through where
- What actions your AI can execute without any deterministic control mediating them
- Whether that calls for a full diagnostic, or two changes you can make yourself are enough
It's not a product demo or a company pitch. If that half hour makes clear you don't need to hire us, we'll tell you right there, and there's no sales follow-up.