Interception screen guide

Use this as the field reference for the primary AIT Cockpit. It explains what each control does, what state you are in, and what evidence you actually have.

The complete operator loop

flowchart LR
    C["Connect"] --> P["Pause"]
    P --> S["Select"]
    S --> E["Edit"]
    E --> D["Decide"]
    D --> V["Verify"]
    V --> R["Rule, repeat, or export"]

AIT does not generate traffic for a real target. It waits between the sending and receiving components until the application produces a message.

Header and next-step strip

The header answers four operational questions:

• Is a listener running?
• Which address must the sender use?
• Is interception on?
• How many messages are paused?

The strip immediately below the header derives one next step from live state. It never forwards, drops, triggers, or edits automatically.

Strip state	Meaning	Operator action
Connect	No active interception session	Open Lab or Start
Pause	Session is running but interception is off	Turn it on if messages should stop
Generate traffic	Listener is ready and the queue is empty	Trigger the sending application
Select	One or more messages are waiting	Select a pending row
Edit	Selected message has no changes	Edit a value or open Attack ideas
Forward	One or more paths changed	Review paths and choose a decision

Left pane: placement and matching

Connections are saved receiver/upstream definitions. A green status mark means a session is using that connection.

Break conditions decide which decoded messages pause. With interception on and no conditions, every decoded message pauses. Start broad in the lab, then narrow by direction or operation on a real assessment.

Live rules are edits previously saved with Apply to future. The hit count shows whether a rule actually matched. Disable or reorder a rule without deleting earlier message evidence.

Center pane: queue and history

Pending shows messages that cannot continue until you decide. History shows completed decisions.

Each row identifies:

• time;
• sending and receiving endpoints;
• request or response direction;
• protocol operation and transport;
• pending, forwarded, dropped, or replayed state.

For stream exercises, select events in the intended release order. The batch toolbar records both the requested and actual order.

Right pane: edit and decision

The body editor is structured and type-aware. Use Envelope for safe transport metadata and Raw only when the decoded editor cannot represent the test. Credential-bearing headers are fully readable and fully editable. Forging, stripping, and downgrading them is how you test whether identity and authority survive an agent boundary, so the tool does not withhold them. A delivery whose credential headers differ from what the sender supplied is marked credential_edited, and chain 2.2 binds the transport envelope into the record hash, so the edit is provable rather than merely applied.

Attack ideas explains locally derived tests for the selected message. Every suggestion includes the exact pointer or delivery action, the boundary being tested, something concrete to observe, and a close control. Prepare edit changes only the editor; delivery still needs an explicit decision.

Open How to use → Offensive ideas for a compact starting matrix, or use the Offensive interception field guide for A2A, MCP, artifacts, callbacks, identity, routing, and lifecycle tests.

Decision meanings

Action	Network behavior
Forward modified	Encode and deliver the body/envelope currently shown
Original	Deliver the immutable original
Drop	Resolve the message without upstream delivery
Duplicate	Deliver correlated copies

An invalid or oversized edit remains pending. It never replaces the original.

Reading “What happened”

After a decision, select the row in History:

1. Sent by agent is the immutable captured content.
2. Delivered by AIT is what left the interceptor.
3. Changed paths names the structural difference.
4. Receiving-agent response is the correlated response, when available.
5. The Lab effect ledger is a separate controlled consequence.

These are different evidence statements:

Evidence	Safe statement
Original differs from delivered	AIT mutated the communication
Receiver returned a correlated response	The receiver processed a delivered request
Controlled ledger/callback/state changed	An independently observable effect occurred
No independent effect	The mutation worked, but impact is not proven

Recommended first assessment

1. Complete all three local exercises.
2. From the successful lab, select Use this setup with my target.
3. Replace only the upstream endpoint or stdio command.
4. Prepare without contact.
5. Select Test target only when authorized.
6. Start a fresh session.
7. Point the real sender at AIT's listener.
8. Trigger one low-risk application action.
9. Forward the original first to establish normal behavior.
10. Reset application state, then repeat with one controlled edit.
11. Export the session and stop with an explicit pending-message choice.

See Assessment deployment for transport placement and Direct interception for CLI automation.

Multi-step attacks

Some boundaries only fail across two messages. A poisoned tool catalogue changes what the client is willing to ask for; an overwritten policy resource changes what it believes is permitted. Neither shows anything until the next message arrives.

A transform rule can guard on another rule having already delivered:

where:
  - path: chain.fires.poison_the_catalogue
    op: gte
    value: 1

Read chain.fires precisely. It counts mutations that reached the wire, not rules that matched. If you drop the poisoned message, forward the sender's original bytes instead, or the rewrite fails to encode, the dependent rule stays quiet. That is deliberate: otherwise the transcript would assert a sequence that did not happen.

Two consequences to expect. chain.self lt 1 gives you fire-once, which is how you keep a two-step attack from leaving a repeated pattern a defender would spot while diffing. And loading any chain guard switches interactive SSE interception to sequential delivery, so an operator pause blocks the stream head-of-line: ordering has to be real for a "did the earlier step land" guard to mean anything.

The claim a chain does not license. chain.fires records that AIT delivered the earlier step before permitting the later one. It says nothing about whether the receiver's second message was caused by the first. The target may have made that call regardless, and ordering within one session is not inducement. Every finding built from a chain states this.

To move from ordering to inducement you need the same close control as any other boundary: re-run the chain with the first step carrying an in-policy value, and compare. To move from inducement to effect you need an out-of-band oracle. A target's own response is neither.

Chained tool-schema attack walks through both arms.

Common mistakes

• Waiting for AIT to send a probe: real-target interception is passive until your application sends traffic.
• Pointing the receiver at AIT: normally only the sender changes; AIT keeps the original receiver as upstream.
• Pausing every response: add direction=request or response after you understand the flow.
• Assuming an edit was delivered: changed paths describe the editor; the decision and History row describe delivery.
• Calling a response “impact”: use an out-of-band ledger, callback, or state observation when the consequence matters.
• Reading a chain as causation: a chain guard proves AIT's ordering, not that the earlier delivery induced the later message. Run the control arm.
• Stopping with paused traffic: choose whether pending messages should be forwarded unchanged or dropped.