Security
Your AI acts. Who is in control?
AI agents read emails, use tools and access internal data. What happens when attackers redirect them? With AI red teaming and pentests we check whether manipulated content can turn into data leaks or unauthorised actions.
We test how far an attacker can get.
AI Red Teaming
We try to redirect your AI through direct inputs and manipulated documents or web pages. In doing so, we check whether safeguards can be bypassed, confidential data read out or unwanted actions triggered.
Penetration tests
We test web applications, APIs and infrastructure for exploitable vulnerabilities. The focus is on login, permissions and data access, including where AI agents are connected to your existing systems.
Agent Security Testing
We test tool access, MCP connections and multi-step agent workflows. Can an agent exceed its permissions, bypass approvals or influence other agents? We follow the attack path through to its possible impact.
One manipulated message. Access to your company.
An agent processes third-party content and can act in your systems at the same time. We check whether attackers can exploit that connection.
- Third-party content turns into commands
- An instruction in an email, a PDF or a search result is meant to pull the agent away from its task. We test whether it treats such content as data or follows the injected commands.
- Permitted tools get misused
- An agent may read data, send messages or change records. We check whether these legitimate functions can be abused for data leakage, unauthorised changes or access beyond the actual task.
- An attack carries on through the workflow
- Manipulated information can end up in the agent's memory or be passed on to other agents. We test whether the attack affects later steps and whether permissions and human approvals contain it.
What you have in hand after the test.
A clearly scoped test
Together we define systems, access, attack goals and limits. You know in advance what we test, which data we use and how we handle critical findings.
Traceable attack paths
You receive documented attack steps and evidence for the vulnerabilities found. We show what access was possible, which data is affected and under what conditions the attack works.
Priorities for remediation
We rate findings by exploitability and potential damage. Your team gets concrete recommendations, such as tighter tool permissions, separated data access or mandatory approvals before critical actions.
Retest of the fixes
On request, we attack the fixed areas again. That shows you whether the measures close the documented attack path or further adjustments are needed.
What we write about AI and security
6 min read
New AI model? Delete everything first, then set up again
More context used to help a lot. With the 2026 models that flips. Why we delete rules, skills and hooks at every model change and bring back only what is missing.
5 min read
AI news October 2026: what companies should know now
New models from Anthropic and Google, a standard for agents in retail and the first conflicts with agents on the open web. What matters for your company.
5 min read
Agentjacking: how a fake error message takes over AI agents
Three attacks from 2026 show the same pattern: an agent reads data from outside and executes it as a command. What happened and which guardrails help.
What you probably want to know
A pentest looks specifically for exploitable vulnerabilities in a defined application or infrastructure. In AI red teaming we pursue attack goals such as data leakage or unauthorised actions and test how the AI's behaviour can be influenced to achieve them. With agents, the two overlap: a manipulated input can lead to a technical vulnerability through a tool call.
These include direct and indirect prompt injection, misuse of connected tools, manipulated MCP tool descriptions, data leakage and bypassing of permissions or approvals. In multi-step systems we also check whether manipulated content stays in memory or is passed between agents. The selection depends on your architecture and the access that is actually available.
A model's safeguards do not automatically cover your entire application. Which data an agent can read and which actions it may carry out is also determined by your integrations, permissions and approvals. That is why we test how the model, tools and connected systems work together.
We agree the test environment, time window and permitted actions with you beforehand. We limit critical actions such as deletions or external messages, or simulate them with test data. Tests in the live system only take place within the scope expressly agreed.
Yes. We also test existing agents, AI applications, web applications and APIs built by your team or by other providers. In the intro call we clarify architecture, access and test goals.
Before going live, and whenever the possible attack routes change significantly: for example through new tools, additional data sources, more permissions or a model change. A test assesses the agreed scope at the time of testing. When things change, the affected attack paths should be tested again.