What does an evidence packageconcretely look like?

Context block

Problem structure

The customer was releasing a new sharing layer (a shared-workspace model in which more than one tenant can grant controlled access). As the release window approached, three questions were not bound to evidence: is the tenant boundary preserved in the new layer, are the old authority checks called on the new endpoints, is the read/write boundary applied consistently in the business logic? The annual automated scan did not answer these questions.

Executive-summary sample

Finding examples

Evidence chain - PoC steps (redacted)

The three steps below show the reproduction logic of Finding 01. All endpoint paths, user identities, tenant identifiers, session tokens and sample values are [REDACTED]; the evidence structure is preserved, its content masked.

1. A request to the share-layer endpoint with a Tenant-X session: GET [REDACTED_PATH]/[REDACTED_RESOURCE_ID] (Authorization: Bearer [REDACTED]).

2. The resource-id parameter was changed to Tenant Y’s record set: GET [REDACTED_PATH]/[REDACTED_TENANT_Y_RESOURCE_ID].

3. Response 200 OK; Tenant Y’s critical record set returned; the ownership check was bypassed. Reproduction confirmed across three separate sessions.

All identifiers [REDACTED]; the sample was produced in a controlled test environment; no real customer data was included in the report.

Decision impact - fix-first backlog summary

The findings are not a single table; they moved into the technical team’s work tracking with a defined owner, a priority tag and a validation logic. A risk view for management and a Jira-transferable field discipline for the product team were delivered together.

• Finding 01 (Critical): close before release · owner: product team · revalidation: mandatory.
• Finding 02 (High): close before release · owner: platform team · revalidation: mandatory.
• Additional findings moved to the next sprint; the closure order and revalidation note were recorded in the executive summary.

Closure note / revalidation

When the fixes were complete, revalidation was performed for each critical finding; the response behavior and the ownership check were retested. The closure note was added to the executive summary; the release decision was carried by evidence. During the customer security-review process, the technical summary and scope statement were shared in a portable form.

The “REDACTED” marker indicates fields from which the customer identity, product name, technology stack, numeric fingerprint and session identifiers have been removed; the structural backbone is preserved everywhere.

Context block

Scenario assumption

The engagement was run under the RT-3 Assume-Breach Simulation frame. The starting assumption: access has been obtained with a low-privilege session on an end-user workstation; the attacker is inside. The question asked: is there an attack path to the critical target (the operational management interface), and does the segmentation and privileged-access control see the attack or miss it? RoE frame: no destructive action, no real data exfiltration, controlled execution; stop criteria in writing; SOC and IR contacts on the emergency line.

Executive-summary sample

Attack-path timeline

The steps below show the attack path from the starting foothold to the critical target, together with the MITRE ATT&CK mapping. All target identities, IPs, session tokens, machine names and sample values are [REDACTED]; the attack structure is preserved, its content masked.

1. Step 1 - Starting foothold

   A workstation session with the [REDACTED_USER] account (T1078 Valid Accounts); starting privilege: standard user. Detection: the SOC saw the user session as routine.

2. Step 2 - Local discovery and credential harvesting

   Local discovery on the workstation (T1083) and cached-credential extraction (T1003.001 sub-technique). EDR raised an alarm, but the reporting process missed the escalation.

3. Step 3 - Lateral movement

   Lateral movement with the harvested credential to the [REDACTED_INTERNAL_HOST] server (T1021); on the crossing from the workstation segment to the management segment, the segmentation control did not apply the expected filter.

4. Step 4 - Privilege escalation

   Privilege escalation in the management segment via a misconfigured service account (T1078.002 + T1068); the privileged-access protection layer did not block this path.

5. Step 5 - Reaching the critical target

   With the escalated privilege, the access boundary of the operational management interface was reached (near TA0040 Impact); it was stopped without taking action within the controlled-execution frame; the SOC raised an alarm and the correct escalation was made.

All identifiers [REDACTED]; the scenario was run in a controlled test window, under written authorization and stop criteria; no real customer data was included in the report.

Detection gap matrix

The matrix below summarizes, for each attack step, in which telemetry source it was seen, missed or partly seen. The goal is to produce a measurable gap list for the SOC and Blue Team; not a blaming frame but control-effectiveness visibility.

• Step 1 - Starting session: SOC full visibility; the routine session was accepted (expected).
• Step 2 - Credential harvesting: EDR raised an alarm; the reporting process missed the escalation (gap #1 - process).
• Step 3 - Lateral movement: network telemetry partly saw it; the segmentation rule produced a gap (gap #2 - control).
• Step 4 - Privilege escalation: identity telemetry saw the anomaly; the alarm priority was low (gap #3 - classification).
• Step 5 - Critical-target access: the SIEM correlation rule raised the correct alarm; correct escalation and a stop were performed (control effective).

Chain-breaking control recommendations

• Gap #1 - Reporting-process escalation rule: a high-priority classification and an automatic IR assignment for the EDR credential-alarm type.
• Gap #2 - Segmentation rule: an allow-list protocol filter on the crossing from the workstation segment to the management segment; an identity-based access boundary.
• Gap #3 - Privilege-escalation telemetry classification: the service-account usage anomaly should be re-mapped as a high-priority alarm type.

Fix-verify work-list

The findings are not a single table; they moved to the technical team with a defined owner, a priority tag and a validation logic. A risk view for management, a work-list for the SOC and platform teams, and a validation plan for the RT-5 scenario repeat were delivered together.

• Gap #1 (Critical): IR process rule · owner: SOC leadership · validation: RT-5 scenario repeat.
• Gap #2 (Critical): segmentation rule · owner: network team · validation: controlled re-run.
• Gap #3 (High): identity-telemetry classification · owner: identity team · validation: a BAS scenario.
• Four additional improvement items were taken into the next sprint plan; the closure order was recorded in the executive summary.

Closure note / RT-5 follow-up

When the fixes were complete, three months later the same attack path was re-run step by step with an RT-5 structured validation sprint; the detection-gap matrix was re-measured. Of the three gaps, control was effective at two, one was partly closed and moved to the next sprint. Management saw that the segmentation investment produced evidence-validated control effectiveness; the RT-5 rhythm became a sustainable validation backbone.

The “REDACTED” marker indicates fields from which the customer identity, product name, technology stack, numeric fingerprint, network identifiers and session details have been removed; the structural backbone is preserved everywhere.

Context block

Agent-workflow definition

The tested workflow: an agent receiving a customer-support request retrieves relevant documents from the knowledge base (RAG) and, when needed, can update the customer record via MCP tools connected to the CRM and billing systems. The agent served three roles: anonymous visitor, registered customer and customer agent. Write-authorized tools were active only in the customer-agent role. The question: can the role boundary be crossed with an indirect prompt injection, can another customer’s record be reached through the agent’s authority?

Executive-summary sample

Abuse-path steps

The steps below show the chain from an indirect prompt injection planted in the RAG knowledge base to the authority leakage, together with the OWASP LLM Top 10:2025 and MITRE ATLAS mapping. All prompt content, source identifiers, agent/session IDs and sample values are [REDACTED]; the chain structure is preserved, its content masked.

1. Step 1 - RAG source planting

   A hidden instruction was planted in a record that looks like a helpful document added to the knowledge base (LLM01 Prompt Injection, indirect - ATLAS AML.T0051.001). The RAG retrieval layer did not classify source trust.

2. Step 2 - Registered-customer request

   A [REDACTED_QUERY] request was sent in the registered-customer role; while fetching relevant documents from RAG, the agent also pulled the poisoned record.

3. Step 3 - System-prompt override

   The hidden instruction overrode the role boundary in the system prompt within the request flow (the LLM02 Sensitive Information Disclosure threat materialised). The agent proceeded without re-evaluating the role context.

4. Step 4 - MCP tool call

   The agent called the [REDACTED_TOOL_NAME] tool on the CRM MCP server with another customer’s record ID; there was no additional authority gate (approval model).

5. Step 5 - Data leakage

   Record data was leaked into the response flow; a masked test record was used within the controlled-execution frame. The write-action attempt was blocked by a stop criterion.

All identifiers [REDACTED]; the engagement was run under written RoE, production approval, stop criteria and masked-test-data discipline; no real customer data was included in the report.

Chain map - prompt → tool → data → authority

The map below summarizes the behavior observed at each node of the chain. Which layer applied a security control, which let it through - the structural view sets the hardening order.

• Prompt layer: the system prompt carries the role context in the first request; re-evaluation in the next turn is missing (chain break-point #1).
• RAG layer: document retrieval works; source-trust classification is absent (chain break-point #2).
• Tool layer (MCP): the tool-call permission matrix is defined at role level; an identity-boundary check on the call parameter is missing (chain break-point #3).
• Data / authority layer: the back-end API applies the record-ownership check at the call-parameter level, not at the agent-identity level (gap #4 - defense-in-depth missing).

Chain-breaking control recommendations

• Break #1 - System-prompt re-evaluation: the role context and action boundary should be re-injected stably at the start of every turn.
• Break #2 - RAG source trust: a trust label for knowledge-base records; at low trust, instruction-looking content should be filtered out.
• Break #3 - Approval model at the MCP tool call: an additional authority gate (user approval or a policy rule) for write-authorized tools.
• Gap #4 - Back-end defense-in-depth: the record-ownership check should also be applied at the agent-identity level; the call parameter cannot be the only defense layer.

Fix-verify work-list

The findings are not a single table; they moved to the technical team with a defined owner, a priority tag and a validation logic. A risk view for management, a work-list for the product team, and a validation plan for the focused retest were delivered together.

• Break #1 (Critical): prompt management · owner: AI platform team · validation: focused retest.
• Break #2 (High): RAG trust label · owner: knowledge-base team · validation: focused retest.
• Break #3 (Critical): MCP approval model · owner: agent-workflow owner · validation: end-to-end retest.
• Gap #4 (High): back-end ownership check · owner: API team · validation: unit test + retest.

Closure note / focused retest

When the fixes were complete, hardening was applied in sequence; the focused retest re-ran the same chain. Control was effective at all three break-points; the back-end ownership check was completed in the next sprint and closure was made visible with an end-to-end retest. Management carried the go-live with evidence; in the agent workflow the interpretation “RAG source trust = implicit assumption” was permanently changed.

The “REDACTED” marker indicates fields from which the customer identity, agent/product name, model provider, MCP server name, RAG source identifier, session token and sample prompt content have been removed; the structural backbone is preserved everywhere.