®Offensive security / AI application security
AI features can be built quickly. But with every data access and every connected tool, the responsibility carried by your application grows. OTOKO® helps teams make AI software and SaaS more secure: from architecture through authorized testing to remediation. 15 years of experience in software analysis and a worldwide OTOKO® team of 95 people form the basis of our collaboration.
Services in detail
Analysis, integration and documented handover
Your brief for OTOKO®
The work packages are derived from your current situation. Your team knows the agreed scope, the required involvement and the results that should be available at handover.
Prompts, documents, search results and tool responses come from different sources. Together, we identify where data is read, processed and passed on, and which decisions must be safeguarded outside the model.
Architecture and data flow assessment with prioritized risks.
Within the authorized test data set, the test examines whether a request can access only the intended documents. Roles and tenant assignment must also align during search, context preparation and answer generation.
Documented assessment of the agreed data access boundaries.
Which actions may an AI trigger, and which need additional approval? Tool permissions, outputs and human decision points are examined across the overall process, instead of leaving the enforcement of boundaries to the model alone.
Requirements and findings on actions, permissions and approvals.
Findings from analysis and testing are turned into actionable changes and repeatable checks. Representative cases support the retest after changes to the model, context, tools or application code.
Prioritized improvements and an agreed regression test suite.
Planning & implementation
An AI feature consists of more than a single prompt. It can retrieve documents, access internal data, send information to services or trigger actions through tools. Its security impact arises from the system as a whole. We therefore look at data sources, roles and permitted actions together. Content from documents or tool responses is treated as potentially untrusted input. The impact this can have depends on the permissions and how the feature is integrated into your application.
The analysis combines classic software concerns with AI-specific risks. Authentication, tenant separation and server-side authorization remain important, even when the user interface is a chat. A model should not decide on its own which data a person is allowed to access. Architecture and control points are assessed so that critical decisions are made outside a free-form response, in a way that can be verified. The specific implementation depends on the system and is coordinated with your development leads.
For a meaningful assessment, representative test roles and datasets are prepared. In a RAG application, for example, the question is whether search results and context assembly observe the intended access boundaries. For agents, the focus is also on which tools are reachable and how tasks are approved. The examination stays within the authorized scope. Producing evidence should not require other customers’ data; a suitable test dataset makes the impact visible in a targeted, controllable way.
Model outputs can vary. A single successful or failed attempt is therefore not taken at face value as a general conclusion. Preconditions, configuration and observed behavior are documented. If a problem only appears under certain conditions, that limitation is part of the finding. Conversely, the absence of an observation is no guarantee for all possible inputs. The report separates proven impact, remaining assumptions and areas that need further review.
“Build fast” and “ship fast” do not have to mean discovering risks only once a system is in production. Together with your team, we translate the analysis results into prioritized changes. These can include tighter permissions, separated data access, validated tool calls and additional approvals for consequential actions. Which measure is appropriate follows from the actual application. A collection of general prompt rules does not replace the work on architecture, identities and permitted data paths.
Relevant test cases can be included in the release process. This means changes to the model, document sources or tools are checked against known requirements. OTOKO® brings 15 years of experience in software analysis and a worldwide team of 95 people working together. Suitable points of contact and a specific scope of services are defined for your project. Working together with your development team combines clear findings with actionable fixes and a foundation for later releases.
Illustrative project scenario
An assistant is meant to give employees access only to the documents permitted for their role. Prepared test roles are used to check search access, context assembly and connected tools. Findings feed into specific permission and integration changes as well as repeatable test cases.
Before you start
No. Critical data access and actions need matching technical boundaries in the application and its connected services. A prompt alone cannot replace this enforcement.
Yes. An existing release can be included in the authorized test plan along with its roles, document sources and integrations. Changes are then reviewed against the agreed test cases.
The assessment can include the upload and processing path. For ongoing file control, an integration of file scanning and CDR can also be planned; each has its own scope of services.
For suitably scoped and provable goals, Result as a Service can be used. Because outputs vary, evidence requirements and the evaluation procedure must be defined especially clearly in advance.
Related services
AI application security with OTOKO®
Name the affected systems and the goal of your request. In the first consultation, we jointly define scope, preconditions and the next steps.
Discuss AI application security
