Build Securely · AI Security
AI Security
Adding an LLM or an agent to a product changes its attack surface. The same request path that makes AI features useful, untrusted input reaching a reasoning engine that can call tools and take action, is also where the new risk lives.
Delivered from our base in Utrecht, available to organisations across the Netherlands.
The problem
Most AI features are built by extending an existing application's architecture to include a call to a model, without extending the threat model to match. The result is systems where a user's free-text input can influence what tools get called, what data gets retrieved, and what actions get taken, often with far more implicit trust than the same application would ever extend to raw user input anywhere else.
Business impact
An AI agent with excessive tool permissions and no output validation isn't a theoretical risk. It's a direct path from a crafted prompt to a real action: an unintended API call, an unauthorised data retrieval, or a business system change nobody reviewed. The more autonomy an AI feature has, the larger the blast radius of getting this wrong.
We review AI features and agentic systems against the risk classes the industry is converging on, grounded in the OWASP Top 10 for LLM Applications.
Prompt injection & indirect injection
Testing how your application handles adversarial input embedded directly in a prompt, or smuggled in through retrieved content, documents, or tool output. Indirect injection is usually the more dangerous variant, since the user never has to write anything malicious themselves.
Excessive agency & tool abuse
Reviewing what an AI agent is actually permitted to do, and whether its tool boundaries, privilege scope and permissions match what it should be able to do, not what was fastest to build.
Insecure output handling
Checking whether model output is validated before it's rendered, executed, or passed downstream: the same discipline you'd apply to any other untrusted input.
RAG & vector store security
Access control and data isolation review for retrieval-augmented systems, so one tenant's retrieved context can't leak into another's, and the vector database itself isn't an unguarded data store.
AI API & machine identity
How AI services authenticate, what scopes they hold, and whether an agent's identity is distinguishable from the user it acts on behalf of: a growing blind spot as agentic systems multiply the number of machine identities in an environment.
Model & AI supply chain
Where your models, weights, fine-tuning data and third-party AI libraries come from, and what could be altered upstream of your application.
AI threat modelling
Structured review of an AI feature before it ships, using the OWASP Top 10 for LLM Applications as a baseline, not the finish line.
AI red teaming
Adversarial testing of a deployed AI system the way a motivated attacker actually would, rather than checking it against a fixed rubric.
AI monitoring & governance
Detecting unusual prompt or output patterns after launch, and the governance structure that decides what AI capability is allowed to touch.
Where attack vectors actually enter an AI application's architecture, from the user's request down to the business systems it can ultimately reach.
The same flow, viewed as a request lifecycle rather than an architecture, showing where each OWASP-LLM risk class sits between input and action.
External Input
Prompt Injection
LLM Reasoning
Insecure Output Handling
Tool / Plugin Call
Excessive Agency
Data / Action
Data Leakage
How this engagement runs
Assess
Understand the current state, real risk, and what's actually driving the need for this work.
Architect
Design the controls and approach that fit your environment, not a generic template.
Implement
Deploy and integrate the work: configuration, code, or process, whichever the engagement calls for.
Validate
Test that it actually holds up, rather than assuming it does because it's been deployed.
Improve
Feed findings back in as your environment and the threat landscape change.
Who this is for
- Product teams shipping an LLM-powered feature for the first time
- Companies building agentic systems with access to real tools, APIs or business data
- Organisations using RAG over sensitive or multi-tenant data
- Businesses that need an AI-specific threat model before a feature ships, not after
What you get
- An AI-specific threat model for your feature or agent
- Prompt injection and excessive-agency testing results with reproduction steps
- A permissions and identity review for any AI agent with tool or API access
- RAG/vector store access-control findings where applicable
- Concrete remediation guidance mapped to the OWASP Top 10 for LLM Applications
Frequently asked questions
What's the difference between AI security and traditional application security?
Traditional AppSec assumes deterministic code: the same input produces the same output, and you can reason about all the paths through it. An LLM is probabilistic and can be steered by the content it processes, which is why prompt injection doesn't have a direct equivalent in traditional AppSec. The disciplines overlap heavily, but AI security adds a genuinely new attack surface on top.
We're using a third-party LLM API (OpenAI, Anthropic, Azure OpenAI). Do we still need this?
Yes. Using a hosted model doesn't secure how your application handles the requests going in or the output coming out. Prompt injection, excessive agency and insecure output handling are all about how your application uses the model, not about the model provider's own security.
What does an AI security assessment actually include?
Threat modelling your specific AI feature, testing for prompt injection (direct and indirect) and excessive agency, reviewing tool/API permissions and identity scoping, and, where relevant, RAG and vector store access control review. Scope depends on what you've built.
Can you review an AI agent that has access to real business systems?
Yes. This is exactly where excessive agency and privilege escalation risk concentrates, and it's a growing share of what we're asked to review as agentic systems move from prototypes into production.
Do you do this only for AI companies, or also for businesses adding AI features to existing products?
Mostly the latter. Most of our AI security work is with organisations bolting an AI feature onto an existing product, which is exactly where the risk is easiest to underestimate because the rest of the application was built with a traditional threat model in mind.
Related services
Related insights
Talk to a security engineer about ai security.
We do not fabricate a client track record here. If you want specifics on how we approach an AI security review, ask us directly.