This is a standardized enterprise security assessment for LLM, RAG, AI agent and MCP toolchains. Within a written authorization we test prompt injection, system-prompt and secret leakage, RAG over-permission, goal hijacking, tool misuse, identity abuse, MCP risk, memory poisoning, unintended code execution, and attack paths from the agent into business systems — and we leave evidence a third party can review.
A chatbot mainly produces text. An agent can read data, decide, call tools and change systems. Host scans, API pentests and model jailbreak lists miss the layer that already holds business keys.
Traditional testing is good at exposure, weak credentials and broken API auth. Many agent incidents use calls that were already authorized — only the goal was rewritten. A passing pentest is not, by itself, an agent go-live argument.
Vendor white papers and jailbreak lists stop at model output. Real impact happens in retrieval, tools, MCP, identity and downstream systems. The path has to be walked until it can be verified.
“Overall risk is high” plus a screenshot does not help leadership decide or engineering fix. An assessment ends in materials different roles can use, not in the atmosphere of a demo.
Each item is tied to a named system, a named input and a named tool. A row that has no object, no precondition and no statement of exploitability does not count as done.
We test whether untrusted input — user text, web pages, attachments, tickets — can rewrite the task or the system instructions. A one-line jailbreak is not enough; we look for whether injection reaches retrieval or a tool call.
We test whether system prompts, tool descriptions, secrets or internal policy can be elicited, retrieved or logged out. A confidentiality sentence in the prompt is not a control.
We test whether retrieval is filtered by identity, and whether neighbouring-team, neighbouring-tenant or higher-classification material can be summarized. “Do not overshare” in the prompt is copy, not authorization.
We test whether external content can turn a query or summary task into send, export, permission change or command execution. After the goal is rewritten, later tool calls often still look like success.
We test whether tool choice, arguments and call order can be driven by instructions outside the task. When a summary task and a privileged tool share one toolbox, one sentence can change the callee.
We test who the agent acts as, where credentials sit, and whether a tool call can be traced to a person, team and task. A shared developer account or an oversized service identity turns one injection into a system-level action.
We look at provenance, version pinning, install approval and credential scope — and at what happens if a server is swapped, a tool list grows, or the server prompt is poisoned while the agent still thinks it is only searching.
We test whether content written into session context or long-term memory is treated as a trusted instruction in a later task. Memory is not a notebook; it joins the next decision.
We test whether a coding agent, or any agent with execution tools, can run commands, change a repository or install dependencies without a human confirmation. Irreversible actions default to human review, not to discovery in logs afterwards.
We follow the path from the agent into tickets, mail, finance, source control or customer data, rather than stopping at model output. Paths should be short, retellable, and name the retrieval or tool call they passed through.
Scope and written authorization come first; controlled testing comes after. From the scope call to the first readout, two to four weeks is typical, depending on how many systems are in scope, how we connect to the environment, and how deep authorization goes. We do not promise a fixed “report in 48 hours”.
A scoping conversation to name the systems, data sensitivity, forbidden irreversible actions, test environment, and what “done” means. Testing does not start without written authorization.
Validation follows agreed task scripts in the agreed environment. KUROSHIO runs exploration and tool calls as the validation engine; people decide the authorization boundary, sensitive actions, and whether to continue.
Input summaries, critical context, tool requests and responses, and whether policy intercepted them, are kept in a form a third party can check. Findings record object, precondition, impact and exploitability.
Security owners and AI / business owners hear what was tested, the few things that matter most, and suggested go-live conditions. Fixed items in scope can be retested on the same path.
If any of these is missing, the work is closer to a concept demo than to an assessment you can file. The product validates paths and keeps evidence; you still decide the risk judgment and whether to go live.
Models, agents, knowledge bases, MCP, accounts and external inputs on one diagram. Someone who did not build the system should see where data enters and where it leaves.
Each risk names an object, a precondition, an impact, and whether it is exploitable now. “Prompt injection” as an abstract label with no system name is not a finding.
Step by step: which input, through which retrieval or tool call, to which result. Paths stay short enough to retell.
Input summary, critical context, tool request and response, and whether policy blocked it. Evidence should be checkable by a third person, not only by the person who ran the demo.
Technical language translated into business meaning: whose data, what action, outage or disclosure, reversible or not.
Written so it can be executed: cut tools, add approval, filter retrieval, split identity. “Strengthen the prompt” is not the only measure.
Fixed items are walked again on the same path. A fix that has not been retested is still a plan.
Within two pages: what was tested, the three things that matter most, and suggested conditions for going live. For people who have to decide, not another technical appendix.
KUROSHIO covers plan, explore, tool-call, validate, evidence and report — as the validation engine. It does not replace scoping, and it does not replace a leadership decision to go live. People keep control of authorization, sensitive actions and conclusions.
Switch between Scope, Explore, Validate and Report in an interactive workspace. See how authorized scope, task orchestration, linked evidence and a report summary fit together, using sample data to illustrate a general assessment workflow.
Yes. Private deployment, isolated networks, whether models leave your boundary, and where logs stay are written into scope before work starts. Data that was not agreed will not leave your environment.
Written authorization; a system list (models, agents, knowledge bases, MCP, tools, identities); test accounts or an agreed access path; a list of irreversible actions that are off limits; and counterparts on both the security side and the AI / business side. Materials can be incomplete; the scope still has to be executable.
We do not test without authorization, we do not touch irreversible production actions without agreement, and we do not provide exploit methods against unauthorized systems. Lab or demo paths explain a method; they are not customer wins or accounts of a real intrusion.
The default pack is the asset map, risk register, attack paths, validation evidence, risk ratings, remediation guidance, retest results and a leadership brief. Scanner output alone, a live demo that cannot be replayed, or a verbal promise does not count as a finished assessment.
The first engagement is an assessment service. KUROSHIO is used as the validation engine during that work. Product deployment, a POC or a private install is a later decision, based on scope and findings — not a prerequisite for starting.
The default is an authorized test or pre-production environment. If production must be touched, only steps that were written down in advance, can be rolled back, and exclude irreversible actions are in play. Nothing happens without written authorization.
Tell us which models, knowledge bases, agents or MCP servers you are running. We begin with authorization and named systems, not with a product pitch.