Fictional worked example · AI products & integrations

How we would assess
an AI assistant with connected tools.

See how document access, generated output and connected actions could become a focused assessment before expanding an assistant’s use. This scenario uses fictional data and does not describe completed client work.

The fictional brief

Start with the decision
the assessment must support.

A fictional organisation is extending an internal AI assistant from searching support guidance to preparing updates to support records. Staff must approve each change before it is applied. The organisation wants to understand the security implications before giving more teams access.

Decision to support
Understand whether the application enforces the intended information access, tool permissions and staff approval controls before expanding the pilot.
System in scope
One staging assistant, its web interface and API, document-retrieval configuration and organisation-controlled connector to a support-system sandbox.
Representative roles
Support colleague, team manager and assistant administrator, with different document access and action permissions.
Information used
Fictional guidance documents and synthetic support records. Testing uses an approved model connection and sandbox; live records and changes to real support cases are outside this proposed scope.
01 / Information

Knowledge bases & RAG

Does your agent use a knowledge base or retrieval-augmented generation (RAG)? Examine what it can retrieve and whether answers respect each user’s access.

02 / Application

Connected tools & MCP

Include connected APIs and Model Context Protocol (MCP) servers in the agreed scope. Examine which tools the assistant can use, what data they receive and what actions they permit.

03 / Actions

Control what your agent can do

Check that your agent can only carry out permitted actions, stays within each user’s access and requests human approval where required.

Planned coverage

Connect each question
to evidence and a boundary.

The OWASP Web Security Testing Guide provides the web-testing baseline, informed by OWASP API security guidance and OWASP LLM application risks. Specialists build on those starting points around the assistant’s architecture, data sources, tools and intended use. They validate findings and interpret their impact.

Proposed coverage only. No testing has been performed and no results are asserted.
AreaQuestion for the assessmentContext and boundaries
Application and API securityDo authentication, sessions, input handling and API permissions protect the assistant and its administration features?Include the surrounding web application and relevant configuration. AI-specific checks build on this application-security baseline.
Knowledge bases, RAG and information accessDoes the agent use a knowledge base or RAG, and can it retrieve or reveal information outside a user’s intended access?Use fictional sources with different access levels. Assess permissions across retrieval and generated answers, including conversation history, logs and caches within the agreed scope.
Instructions and generated outputCould instructions in a request or source document redirect the assistant, or could generated content be handled unsafely by the application?Assess prompt-injection risks and output handling in the agreed workflows. Specialists validate the security impact; this is not a general answer-quality benchmark.
Connected tools, MCP and approvalWhich tools, APIs or MCP servers can the agent access, and are permissions and staff approval enforced before it acts?Assess the authorised connections, the data shared with them and the actions they allow. Use synthetic sandbox records to check role permissions and approval for the intended action and record.
Failure handling and usage controlsWhat happens when a tool fails, a request is repeated or an action is refused, and are agreed usage limits enforced?Examine the application’s handling and relevant logs within agreed request and cost limits. Uncontrolled load and changes to live systems are excluded.

Before testing

Make the boundaries
and preparation explicit.

Included scope has limits.

  • The scope is the named assistant, application and authorised connections. The model provider’s infrastructure and wider support platform are not assessment targets.
  • The approved model connection and data route must meet your requirements. Where a simulator replaces a live integration, its limitations are recorded in the agreed scope.
  • No live support records are changed. Availability-impacting work and unrestricted model usage are excluded unless specifically agreed.
  • Results relate to the tested configuration and workflows. This is not a complete AI governance audit, certification or guarantee that every possible model response is safe.

What to prepare.

  • A representative staging assistant and architecture overview showing its knowledge base or RAG setup, connected tools, any MCP servers and model connections.
  • Test accounts, document-access rules, permitted actions and a clear definition of when staff approval is required.
  • Fictional documents, synthetic support records and authorised sandbox access, with known differences from production.
  • A technical contact, written authorisation, permitted test windows, request and cost limits, and an agreed escalation route.

Your assessment report

Clear findings.
Practical next steps.

Your report helps you understand the findings and gives your technical team the detail needed to act on them.

What your MurtaSec assessment report includes.
Report section What it contains How it helps
Executive summary A clear overview of the assessment’s key findings and their implications. Give decision-makers a concise view of the risks that need attention.
Summary of findings An overview of the individual findings in one place. Review the issues together and plan the next steps with your team.
Finding details Each finding includes a description, reproduction steps, remediation steps and references. Help your technical team understand the issue, reproduce it and work through the recommended fix.

Let’s plan
your assessment.

Use this example as a starting point. Tell us how your workflow differs, what you need to learn and any requirements the assessment must address.