Contact

Agentic security

We test superintelligence (SI) agents against attack, then limit what they can reach. Every finding comes with the run that shows it.

Test an agentSee what we test

Why agents need their own tests

An agent reads text anyone can write, and acts on it with real permissions.

Agentic security is the testing and control of SI agents and the tools, data and credentials they reach. We test direct and indirect prompt injection through pages, emails, files and tool results. We also test changed tool descriptions, excess privilege and poisoned memory.

Planted instructions can change what an agent does. The agent cannot always tell them apart from the task it was given.

The damage is set by its access. An agent that can read every file and call every tool can be turned against all of them.

We test what an agent does under attack, then cut its access to what its task needs.

What to test before an agent buys on your behalf

Prompt injection and tool misuse tests

Each attack runs against your agent, its tools and its data, and every run is logged.

Where an injected instruction reaches the agent

Direct

  • User message

Indirect

  • Retrieved document
  • Web page
  • Email
  • File
  • Tool result
  • Memory
AttackWhat we checkOWASP reference
Direct and indirect prompt injectionWhether instructions sent in a user message (direct) or planted in pages, emails, files and tool results the agent reads (indirect) change what it does.LLM01:2025, ASI01
Tool misuseWhether the agent can be steered into calling a tool it should not call, or with arguments it should not send.ASI02
Data leaksWhether private data in the agent's context or tools can be drawn out through its answers or its tool calls.LLM02:2025
Excess privilegeWhether the agent's credentials reach more than its task needs.LLM06:2025, ASI03
Poisoned memory, retrieval and contextWhether planted content in memory, retrieved documents or earlier turns changes later decisions.ASI06
Tool poisoning and changed tool descriptionsWhether instructions hidden in a tool's description, or a description that changes after approval, can redirect the agent.ASI02, ASI04
Agent to agent pressureWhether one agent can push another into actions its own instructions forbid.ASI07
Escalation and honest reportingWhether the agent hands off to a person when it should, and reports what it actually did.

OWASP reference: the matching entries in the OWASP Top 10 for LLM Applications 2025 (LLM) and the OWASP Top 10 for Agentic Applications for 2026 (ASI), read 6 Nov 2026.

  • Black-box by design

    Agents are tested only through what they receive and what they return. Any model family can be tested the same way.

  • Pinned model versions

    Each test names the model family and the pinned version it ran on.

  • Replayable runs

    Every run is logged, so each finding can be replayed step by step.

Scope an attack suite

MCP servers and tool connections

A Model Context Protocol (MCP) server connects an agent to tools and data. The agent reads every tool description and result the server sends as text it may act on.

Tool poisoning
Instructions hidden in a tool's name, description or input schema, which the agent reads before it calls the tool.
Changed descriptions
A tool whose description changes after it was approved, so the agent follows text no one reviewed.
Instructions in tool results
Text a tool returns that tries to steer the agent's next step.
Servers that reach too far
Credentials or tools on a server that reach more than the agent's task needs.

In the agents we build

Each tool server reached with scoped credentials, an allow-list, a policy check and a log line on every call.

Glesso: governed access to business tools for SI assistants. Each customer's credentials are encrypted and used only for that customer's own requests.

Review your MCP servers

Agent permissions and access controls

These controls guard against excessive agency, an agent that can do more than its task needs. Every tool call passes a policy check, and everything the agent reads back is treated as untrusted.

A governed tool callFive steps from left to right. A user asks for a task. The agent plans the next step and asks for a tool. A policy check confirms the tool is allow-listed, the credentials are scoped to the task, and a person approves any consequential action. The tool runs on the task's own credentials. The result is marked untrusted before the agent reads it, and goes back to the agent. Under every step, an audit log records each request, check, call and result with its time and identity.Results go back to the agent marked untrustedUserasks for a taskAgentplans the next stepand asks for a toolPolicy checkallow-listed tool,scoped credentials,approval if consequentialToolruns on the task'sown credentialsResultmarked untrustedbefore the agent reads itAudit log: every request, check, call and result, with time and identityA governed tool callFive steps from left to right. A user asks for a task. The agent plans the next step and asks for a tool. A policy check confirms the tool is allow-listed, the credentials are scoped to the task, and a person approves any consequential action. The tool runs on the task's own credentials. The result is marked untrusted before the agent reads it, and goes back to the agent. Under every step, an audit log records each request, check, call and result with its time and identity.Userasks for a taskAgentplans the next stepand asks for a toolPolicy checkallow-listed tool,scoped credentials,approval if consequentialToolruns on the task'sown credentialsResultmarked untrustedbefore the agent reads itResults go back to the agentmarked untrustedAudit log: every request, check,call and result, with timeand identity
A governed tool callEvery step is logged

  • Scoped credentials

    Each task gets credentials that reach only what it needs, for as long as it needs them.

  • Allow-listed tools

    The agent can call only the tools on its list, with the arguments its policy allows.

  • Approval before consequential actions

    Payments, deletions and messages sent outside wait for a person to approve them.

  • Untrusted content marked

    Pages, files and tool results reach the agent marked as data from outside, never as its instructions.

  • Checked citations

    Each citation is matched to retrieved evidence before it reaches the user. Grellum, our legal research system, works this way.

  • Audit logs and revocation

    Every call is logged with its time, identity and result, and any credential can be revoked at once.

Review your agent's access
Permission-aware retrieval for internal assistants

Where agents run

The platform under an agent sets how far an attack can spread.

  • Tenant namespacesEach tenant runs in its own space, with its own credentials.
  • Network-policy isolationEach workload gets only the network paths it needs. All other traffic is denied by default.
  • Admission policiesThe platform rejects workloads that break policy before they start.
  • Reviewed changesDeployments are declared in version control, reviewed and deployed from it.
  • Client data in placePrivate deployments keep client data in the client's environment.

109 access, admission and network tests passed for tenant isolation on the Rillor platform, 7 Oct 2026

What the 109 isolation tests check

Access tests confirm that a tenant's credentials reach only its own resources. Admission tests confirm that the platform rejects workloads that break policy. Network tests confirm that traffic between tenants is blocked. All 109 passed on the Rillor platform on 7 Oct 2026.

Security risks in self-hosted LLM deployments

How an engagement runs

We test agents whoever built them, as an engagement of its own or inside a system we build. Four steps take it from a written scope to a confirmed fix.

  1. Scope

    We map the agents, the tools and data they reach and where they run, and agree in writing what we test.

  2. Test

    We run the attacks on pinned model versions and log every run.

  3. Fix

    We work with your team to close each finding, from narrower credentials to new approval steps.

  4. Retest

    We rerun every attack that succeeded and confirm each fix with a new run.

What you receive

Findings come with the runs behind them.

  • Findings report

    Each finding with the replayable run that shows it and the fix for it.

  • Attack suite

    The attacks we ran, packaged to rerun on each new model version.

  • Hardened deployment

    The agent's credentials, tools and approvals cut to what its task needs.

How we evaluate agents

What a finding looks like

Each finding in the report is one record, with the same fields every time.

Attack
The attack and the channel it came through.
Agent and model
The agent and the tools and data it reached, with the model family and pinned version of the run.
What happened
Each step the agent took, from the planted input to the action it took or the data it exposed.
Run
The logged run that shows the finding, which replays step by step.
Fix
The change that closes it, from narrower credentials to a new approval step.
Retest
The new run that confirms the fix.

Common questions

  • What is prompt injection?

    An attack that plants instructions in text an agent reads, so the agent follows them in place of its task. An agent cannot always tell planted instructions apart from the task it was given, and it acts on them with real permissions.

  • What is indirect prompt injection?

    Instructions planted in content the agent reads during its work: a retrieved document, a web page, an email, a file, a tool result or its memory. Direct prompt injection arrives in a user's own message. We test both.

  • Do you test MCP servers?

    Yes. We test the MCP servers an agent connects to for tool poisoning, descriptions changed after approval, instructions in tool results and access beyond what the task needs. In the agents we build, each tool server is reached with scoped credentials, an allow-list, a policy check and a log line on every call.

  • Do you test agents you did not build?

    Yes, as an engagement of its own. We test only systems you own or are authorized to test, within a written scope.

Research

The newest articles from our Insights library, each with a full research report and its sources.

  1. Research reportPoisoned memory and retrieval: what published attacks showRAG poisoning and memory poisoning plant text that superintelligence (SI) agents later retrieve and act on. What published attacks, disclosed cases and tested defenses show.Agentic security7 min readPDF report
  2. ExplainerPrompt injection vs jailbreak: two different failuresA jailbreak defeats a model's safety training. A prompt injection makes an application obey untrusted text. How to tell them apart, and why it matters for superintelligence (SI) agents.Agentic security7 min readPDF report
  3. Methods noteIndirect prompt injection: testing every channel an agent readsIndirect prompt injection reaches superintelligence (SI) agents through what they read. A test plan for each channel: documents, web pages, email, tool output, retrieved data and images.Agentic security7 min readPDF report

Notices

SI outputs. Superintelligence (SI) outputs can be wrong. Important decisions should include human review.

Security testing. Rillor tests only systems the client owns or is authorized to test, within a written scope.

Test your agent before it holds real access.

Send us the agents, the tools and data they reach, where they run and what you want tested.

Test an agent