Every professional offensive security engagement runs under Rules of Engagement (RoE): what may be tested, when testing may occur, and who to contact when something goes wrong. NIST SP 800-115 treats that document as binding. The catch is that traditional RoE is static. You agree once, then live with it for a four-to-eight-week assessment that ends.
Continuous programs do not work that way. The same application can run Discovery, Probing, Signal Generation, Security Test Case, and Attack on different schedules, with different risk, across web apps, AI applications, and network surfaces. One briefing that loads everywhere either dumps late-stage context into early recon, or leaves Attack without the guidance it needs.
Testing Instructions in Terra Platform™ are Terra’s version of that discipline for programs that do not stop. Instead of one RoE doc per application, you get guidance scoped by pipeline, attach mode, and endpoint pattern.
What Testing Instructions carry
Agents cannot invent every operational constraint from the target alone. How authentication works, which flows matter, which paths to treat carefully, what the environment assumes: that has to come from you. Testing Instructions are that briefing, saved on the target and applied with more precision than before.
Until this work, routing was coarse. You could not choose which pipeline an instruction belonged to, how it should attach, or which endpoint families it covered. Three changes fix that.
1. Scope by pipeline
Terra’s testing loop moves through distinct pipelines. On web and AI applications, you can aim an instruction at:
- Discovery
- Probing
- Signal generation
- Security test case
- Attack
For Always and Auto-attached instructions, pick the pipelines where the guidance belongs. Leave the list empty to apply to all of them. Network surfaces use the same idea with the pipelines they support: Signal generation, Attack, Discovery, and Probing.
Say you have authentication steps for a sensitive admin API. Put them on Signal generation, Security test case, and Attack. Leave Discovery and Probing alone. Early recon stays light. Later stages get what they need. That is stage-specific RoE without rewriting a document every time the cadence changes.
2. Control how instructions attach
Not every instruction should ride every step of every run. Each Testing Instruction has an apply mode:
Always is for baseline context. Auto-attached is for a route or service family. Agent-requested is for deep or sensitive context that should stay available without flooding the run. Manual is for operator-driven Copilot work.
This controls attachment. It does not replace platform safety policy. Guardrails still define what agents may and may not do (Block, Warn, or Log). Testing Instructions shape how agents approach an approved target inside those boundaries.
3. Target endpoints with glob patterns
Category labels alone were a blunt tool for microservice and versioned APIs. Endpoint patterns (glob matching) let an Auto-attached instruction hit the paths that need it, for example /api/v2/billing/** or /api/admin/**, without picking every route by hand or applying the rule to the whole app.
The same Testing Instructions model covers web applications, AI applications, and network targets. Globs matter most where path structure maps to ownership and risk. Elsewhere, pipeline scope and apply mode still give you control.
A complete instruction might look like this:
- Name: Admin API authentication
- Apply mode: Auto-attached
- Pipelines: Signal generation, Security test case, Attack
- Endpoint patterns: /api/admin/**
- Content: the authentication steps agents need for that surface
Use a specific operational title. A generic category label is fine for organization, but a path- and stage-scoped instruction reads clearer with a concrete name.
How this fits with Guardrails and Memories
People mix these up. They are different jobs:
This work sharpens Testing Instructions. It does not replace Guardrails or Memories. You configure all three under Testing Controls for the application or surface.
What this means
Testing Instructions stop being a single form field and start behaving like a real config layer for continuous offensive security.
Security teams get stage-appropriate guidance instead of lowest-common-denominator rules. They choose, instruction by instruction, whether context is always on, pattern-triggered, agent-requested, or pulled in via Copilot @mention. And they can aim that context at the parts of the system that actually need it, across web, AI, and network targets.
Blunt instructions break down as continuous programs grow. Testing Instructions keep the operational detail those programs need, and put Rules of Engagement into a shape that matches testing that keeps going.
