Research Under the surface
AI security research into agents, shared data boundaries and cloud identity.
We also explore AI-assisted security testing methods. Both lines of research are in progress, not released products or reported findings.
The visible surface is only part of the system.
Question the assumption.
Follow the evidence.
Research focus
The questions below concern security of AI systems: where information, identity and authority change hands. Our parallel AI-assisted security testing work is exploratory; these questions do not describe a product or a published result.
01Intent & action
We investigate how an agent handles instructions embedded in retrieved documents, tool responses and other untrusted context. The question is what separates information it can read from actions it can take.
Prompt injection · Tool permissions · Approval boundaries
02Data & isolation
A shared index, context cache or memory store still needs to respect each user's access. We examine where identity and access checks apply as information moves from storage into a model's context.
RAG retrieval · Tenant filtering · Shared memory
03Identity & reach
We study the relationship between a requested task, the agent executing it and its cloud workload identity. Which permissions are necessary, which are inherited, and what remains reachable if the agent is compromised?
Workload identity · Delegated access · Runtime isolation
A worked question
A user approves a bounded task. Later, retrieved content changes the action or its target. The original approval may no longer describe what the agent is about to do.
The research question: does enforcement evaluate the final request, or rely on a decision made before it changed?
Illustrative scenario. Not a reported vulnerability or a client finding.
| Check | Approved task | Proposed action |
|---|---|---|
| Identity | Same user | Same user |
| Action | Read a record | Export records |
| Resource | Tenant A | Tenant B |
Authorisation must match the action and resource at execution—not just an earlier version of the task.
From anomaly to evidence
Research needs more than a convincing demonstration. It needs conditions another investigator can examine, and a conclusion that survives being challenged.
What would change
our conclusion?
Name the boundary that should hold. Record the system, identity, permissions and sequence needed to test it.
Compare the observed behaviour with a control. Change relevant conditions and consider simpler explanations before assigning a cause.
Repeat the test, record variation and examine counter-evidence. An inconsistent result narrows the claim; it is not a reason to hide uncertainty.
Keep the conclusion tied to tested conditions. Distinguish the demonstrated mechanism, untested cases and proposed fixes that still need validation.
Research into defence
The purpose is practical: sharper test cases for red teams, clearer enforcement points for engineers, and better questions for defenders to ask of their telemetry.
A useful result explains where a control belongs, what it must check and which conditions a retest needs to cover.
See how we assess your systemsResearch enquiries
Working on an agent, retrieval system or cloud architecture with a boundary you need to understand? Tell us what it should prevent and where the uncertainty begins.
Start with a high-level description, not credentials or sensitive evidence.
