RINP // CYBERSECURITY SERVICES
AI Security · AIS-1 · Runtime Chain Validation
In generative AI products, we verify the runtime attack paths that can actually be exploited.
We test the prompt, RAG, tool, MCP, and authorization flows under controlled conditions. We verify abuse paths through a safe PoC. We report the findings, prioritized by data and business impact, together with the controls that break the chain.
- The prompt, RAG, tool, MCP, and authorization chain is assessed end to end.
- The impact of agent behavior on data access and action privileges is verified through a safe PoC.
- The controls that break the chain are tied to go-live and remediation priority.
4 surfaces
- 01
<em>Prompt</em> & orchestration
System prompt, safe execution
- 02
<em>Tool</em> & connector
Permission matrix, write-capable abuse
- 03
<em>RAG</em> retrieval
Access control, data exposure
- 04
<em>MCP</em> & authority
Authorization, token, approval
Controlled PoC · attacker's eye
What this service is, and is not
- It tests the runtime flow in the generative AI product against threat scenarios under controlled conditions.
- It verifies the abuse paths that arise across prompt, RAG, tool, and MCP through a safe PoC.
- It grounds the executive summary, technical report, and chain-breaking control plan in the same verified findings.
- Not AI Model Supply-Chain Assurance; where the model comes from and how it is produced open a different decision moment.
- Not AI for Pentest & Red Team; accelerating the internal offensive-delivery workflow with AI is a separate decision.
- Not a prompt-injection-only test, an attack on provider infrastructure or uncontrolled aggressive testing with real data; it runs within written agreement, controlled PoC, a test account, a stop criterion and rollback coordination.
Scope and boundaries
- LLM and agent orchestration layer; system prompt, safe execution boundaries, input and output handling
- Tool and connector calls; permission matrix; abuse-path testing on write-capable tools
- RAG retrieval behavior, access control, data exposure and retrieval manipulation
- MCP authorization, approval, token management, token-passing abuse, session and tool-exposure controls
- Where applicable, API, authentication, authorization and business-logic controls
- Abuse-path evidence with a safe PoC: timeline, technical trace and reproducible steps
- Chain-breaking control recommendations and a fix-first work list (owned, ordered)
- Decision support for management + an actionable work list for the technical team (two-layer delivery)
- Black-box attack testing on the model provider's own infrastructure
- Source provenance, component list and registry assessment within AI Model Supply-Chain Assurance
- DoS, stress, load testing or establishing persistence
- Social engineering or physical testing
- Access to or testing of unauthorized third-party systems
- Destructive action, production impact or uncontrolled data exfiltration without written agreement
- Setting up an autonomous attack agent or fully automated exploit generation
- Written authorization, rules of engagement (RoE), stop criteria and rollback coordination are approved.
- A test environment, test accounts and, where needed, a production-like environment are shared; testing on production is only by written agreement.
- The system prompt, safe execution boundaries, tool catalog, permission matrix, RAG data-source list and MCP server summary are shared.
- High-impact actions (write, execute, admin, payment, delete) require written approval; tests are limited to a controlled PoC.
- The starting price is an approximate budget; the final proposal narrows once architecture, permission model, data sensitivity, provider constraints and the test window are clear.
- Product and workflow goal; user roles and permission matrix
- Test environment and accounts; the system prompt and safe execution boundaries
- Tool catalog, RAG data-source list, MCP server summary
- VPN, MFA, IP allowlist and escalation contacts; a reachable technical contact for emergency stop
- Optional: architecture summary, threat-modeling outputs, third-party contract constraints, reporting language (TR / TR+EN), previous AI security assessment reports
Testing is carried out with written authorization, test accounts, permitted tools, approval gates, stop conditions, and a rollback plan.
How we work: six steps from architecture to remediation plan
Scope, RoE & access validation
Written authorization, rules of engagement (RoE), stop criteria, rollback coordination, the test environment and accounts, the agent-workflow scope, and the RAG and MCP surface are defined; the starting view is drawn.
Architecture reading & attack-surface mapping
The system prompt, safe execution boundaries, tool catalog, permission matrix, RAG data sources, MCP servers and action classes (read-only, limited write, high-impact) are read; the attack-surface map is drawn.
Threat modeling & scenario design
Prompt-injection, indirect-prompt, RAG-exposure, tool-abuse and MCP-authorization-abuse scenarios are designed by workflow goal, agent authority and action class; OWASP LLM and Agentic Applications references are checked.
Prompt, RAG, tool, MCP & identity tests
We test prompt injection, RAG access control, tool abuse, MCP authorization, and agent actions within the approved boundaries through a safe PoC.
Finding confirmation & risk prioritization
We evaluate the verified findings together with data impact, action privileges, and business risk to establish remediation priority.
Reporting and control verification
We deliver the executive summary, technical report, safe PoC, and chain-breaking control recommendations; once the client applies the controls, we run a post-remediation retest at the appropriate scope.
What we deliver
Executive summary
- Risk picture: explains the verified abuse paths in terms of data and business impact.
- Go-live summary: shows the controls to apply first and the residual risk.
- Retest result: shows the status of the abuse path after the client applies the controls.
Technical report and security records
- Technical report: explains the findings across the prompt, RAG, tool, MCP, and authorization chain.
- Safe PoC: shows the steps needed to reproduce the abuse path in the test environment.
- Control plan: lists the permission, approval, logging, and data-access controls that break the chain.
- Shareable technical security records: bring together the test traces, screenshots, and the affected flow.
Optional outputs
- Focused retest: within 30 days, a separate line for only the fixed findings.
- End-to-end retest: a separate line for revalidating the entire chain.
- Secure Agent / MCP workshop, a hardening session, threat modeling or bilingual reporting: priced as a separate line when needed.
Management sees the controls required for go-live. Product and security teams follow the abuse path, the technical finding, and the remediation order.
Decision profile
- Duration
- 2–4 weeks (by scope and package)
- Rhythm
- Controlled PoC + approval gates
- Delivery
- Management + technical
- Scope
- Agent workflow, tool, RAG, MCP, authority
- Best for
- Product and agent teams with GenAI applications
Which is the right start, and when?
These three approaches do not produce the same evidence object. Starting without knowing the difference wastes time and budget chasing the wrong proof.
| Criterion | ÖnerilenGenerative AI Red Team | AI Model Supply-Chain Assurance | General AI security assessment |
|---|---|---|---|
| Decision question | At runtime, which chain truly breaks, and which control cuts it? | What do we truly trust about the model and the release pipeline? | Where does our AI risk surface stand against a general checklist? |
| Primary evidence object | Broken runtime chain, abuse path, agent behavior, chain-breaking control | Source provenance, component list (BOM), attestation, registry / release trust | Checklist result, posture score, generic risk map |
| Ideal trigger | Go-live of a GenAI product; adding a new tool, connector or MCP; agent authority rising to write/execute | Model-pipeline source and registry trust pressure; an internal or regulatory evidence-pack need | A general AI risk-awareness round; a panoramic summary for senior management |
| Wrong match | Meeting a model-trust-chain need with a runtime-chain test | Meeting a runtime-chain need with model supply-chain assurance | Substituting a generic checklist result for a proven-chain decision |
One example of decision clarity
Anon case
Before agent go-live: what can the authority, RAG and MCP chain truly do?
A product team scoped us to test the runtime flow of their agentic application that uses RAG and tools before going live. Together we defined the test accounts, permitted actions, and stop conditions.
Our controlled testing revealed an abuse path in which crafted content led the tool to access data it was not authorized for. We verified the chain with a safe PoC and technical traces.
We delivered the executive summary, the technical report, and the chain-breaking control plan. After the client applied the authorization and approval controls, our retest confirmed that the abuse path was closed.
What this case produced
- The go-live decision was made based on a verified abuse path.
- The data-access impact was verified through a safe PoC.
- The authorization and approval controls were verified through a retest.
Let's clarify your agent-workflow scope together
In this form we clarify the product's prompt, RAG, tool, MCP, identity, and authorization flows, along with the test accounts and permitted actions.
Frequently asked questions
GenAI Red Team tests the product's runtime flow and agent behavior. Model Supply Chain Assurance, on the other hand, examines the model's origin, components, and distribution pipeline.
This service tests the client's GenAI product. To improve an internal penetration testing team's AI workflow, the AI for Penetration Testing and Red Team service is used.
The provider's infrastructure is not tested. Production work is carried out with test accounts, limited permissions, approval gates, and stop conditions.
The prompt, RAG, tool, MCP, identity, and authorization flows are assessed together. The executive summary, technical report, safe PoC, and control plan are delivered.
The architecture flow, test accounts, tool and MCP list, RAG data sources, permission matrix, test environment, and escalation contacts should be shared before the engagement.
Least-privilege, human approval, test data, logging, and rollback controls are applied. Destructive actions and unauthorized data access are kept out of scope.
Related services and add-ons
If your need extends beyond the Generative AI Red Team, open the right bridge here.
AI for Pentest & Red Team
If the focus is controlled acceleration of the internal offensive-security team's discovery, evidence, reporting and retest workflow with human-supervised AI, AI for Pentest & Red Team is the right start.
RTModular Red Team Simulation
If the focus is the attack path to the crown jewels, business impact and the detection gap, the Modular Red Team Simulation is the right start.
PT-1Application Security Penetration Test
If the focus is critical-flow, authority, tenant and business-logic flaws on the underlying web, API and mobile surface of the GenAI product, the Application Security Penetration Test is the right start.
// AIS-1 · DISCOVERY
Let's clarify the agent flow, data access, and permitted actions together.
In the discovery call we define the prompt, RAG, tool, MCP, identity, and authorization scope, the test environment, and the expected evidence together.