BOTNETSECURITY
Client Portal Request Assessment
Menu
AI APPLICATION SECURITY / MCP

Verify every handoff from model context to tool execution.

Model Context Protocol can connect conversational context to tools with material permissions. Testing follows the complete chain: what a client discovers, what a server advertises, which identity authorizes an action, what parameters reach the tool, and how the downstream system enforces access.

Discuss scope Review coverage
AUTHORIZED ENGAGEMENT MODEL
01Chain02Constrain03Enumerate04Challenge

REQUEST → SCOPE → AUTHORIZE → KICKOFF → EXECUTE

ENGAGEMENT LENS

Each boundary is tested independently, then examined as part of the complete path.

  1. CLIENT
  2. CONTEXT
  3. MCP SERVER
  4. TOOL
  5. DOWNSTREAM

TRUST BOUNDARY / CONTROL EVIDENCE

01

ASSESSMENT BOUNDARY

What is being assessed?

The engagement boundary is defined by systems, identities, workflows and restrictions—not only a list of URLs or assets.

  • In-scope MCP clients and servers
  • Tool discovery, descriptions and parameter handling
  • Authentication, session and authorization design
  • Context manipulation and untrusted content paths
  • Credential and secret exposure
  • Downstream API and data boundaries
02 / TEST MODEL

What Botnet tests.

Coverage follows reachable trust decisions and agreed risk, with destructive or disruptive actions excluded unless explicitly authorized.

01

Discovery

Which servers, tools and capabilities are visible to each intended identity.

02

Identity

Authentication, session binding, delegated access and credential handling.

03

Tool boundary

Parameter validation, authorization and confirmation around material actions.

04

Context influence

How untrusted instructions or retrieved content affect tool selection and inputs.

05

Server trust

Assumptions between client, MCP server and downstream service.

06

Evidence path

Controlled validation of customer-approved actions without implying unrestricted execution.

03 / ENGAGEMENT

How the work progresses.

  1. 01

    Chain

    Map client → context → server → tool → downstream system.

  2. 02

    Constrain

    Agree identities, tools, test data and prohibited actions.

  3. 03

    Enumerate

    Review discoverable capabilities and effective permissions.

  4. 04

    Challenge

    Test manipulation, authorization and input boundaries.

  5. 05

    Correlate

    Relate MCP behavior to the downstream API and data control.

  6. 06

    Report

    Assign findings to the component where the control must hold.

04

EVIDENCE + ACTION

What the customer receives.

  • MCP trust-chain diagram
  • Tool and identity exposure summary
  • Reproducible security findings
  • Affected component and downstream impact
  • Remediation guidance and limitations
  • Technical readout and agreed re-test result
05 / BOTNET APPROACH

Evidence over assumption.

01End-to-end tool-chain reasoning

02Authorization tested beyond model behavior

03Explicit distinction between context influence and executed impact

04Evidence mapped to client, server, tool or downstream owner

06 / QUESTIONS

Before scoping.

Do you support every MCP client and server?

No. Specific products, transports and implementation details must be confirmed during scoping.

Will tests execute real tool actions?

Only customer-approved actions within the Rules of Engagement. Destructive, sensitive or external actions are excluded unless explicitly authorized.

Is MCP testing included in an AI assessment?

It may be related, but MCP scope, tools and downstream systems should be named explicitly.

NEXT STEP

Define the target, constraints and required evidence.

An assessment request starts a scoping conversation. It does not authorize testing. Work proceeds only after scope acceptance, executed authorization/SOW and kickoff.

Request assessment Contact the team