AI agent security and compliance

Agentic AI security covers what an agent can do, not only what it says: which tools and data it can reach, which actions wait for a person's approval, and how every tool call is logged. Prompt filters help, but the controls that hold are enforced in code, outside the prompt.

Three parts. A threat model and a data flow map for each agent, with the GDPR and EU AI Act obligations that may apply. Controls in code: least-privilege tools with scoped credentials, approval steps for irreversible actions, input and output checks, outbound channels closed after untrusted input, and a red-team suite in your CI. Then the records: audit logs for every tool call, retention rules per data type, technical documentation for your compliance review, and runbooks for your security team.

Nobody can promise that, and we do not. Any agent that reads outside content, such as supplier emails, uploaded files or search results, will meet an injected instruction at some point. We design for that moment: the agent holds only the tools its task needs, irreversible actions wait for a person, and the injection cases from your threat model run as tests on every release.

It will try, through any channel that leaves your environment: a link, an image the chat window loads, an HTTP call, an email. A run that has read untrusted content and has access to private data gets no outbound link, image or HTTP call unless a person approves, and sending waits for a person. Red-team cases cover these channels on every release.

No. We are engineers. We list the obligations that may apply to the system, build the technical side (data minimization, retention, logging, human oversight, technical documentation) and give your legal and compliance team the records they need to decide. Classifying the system under the EU AI Act, and any conformity assessment, stays with your lawyers and, where the law requires one, a notified body.

Each tool the agent can call gets the narrowest scope its task needs: read access where it only reads, one customer's records rather than the whole table, a refund limit rather than an open payments API. The limits live in the code and in the credentials, so a manipulated prompt cannot widen them.

We turn the threat model into red-team cases: injected instructions in documents, requests for another user's data, attempts to reach a tool outside the task, questions about the system prompt. The cases sit in your CI next to the quality tests, so every prompt, model or tool change runs them again. New cases are added when the logs show a new kind of attempt.

We map that before writing code: what the agent reads, what goes into the prompt, what is kept in memory and in logs, and which model provider receives it. The agent can run in your cloud account, memory stays with the user it belongs to, and logs are deleted on the schedule you set.

Yes. We start from the threat model and the data flow of the live system, run red-team cases against it and give you a ranked list of fixes. Then we either make the fixes or hand them to your engineers.

A threat model and a data flow map for each agent, the control code in your repository, the red-team suite in your CI, audit logs in your environment, and runbooks for the people who will look after the system. All of it is yours to change, extend or take to another team.