Bounded cyber agent roles: define the job before the prompt

A specialist name can improve focus, but it does not define authority. Before writing a role prompt, specify the decision it supports, the evidence it may use, the artifact it must produce and the conditions that require escalation. Runtime tools and permissions should be granted separately.

A useful role contract has six parts

• Inputs: approved evidence, environment context and source quality.
• Core decisions: the questions this specialist is expected to answer.
• Deliverables: a stable artifact schema another role can review.
• Boundaries: prohibited claims, systems and actions.
• Escalation: uncertainty, severity and conflict conditions.
• Definition of done: evidence and handoff criteria, not just a polished narrative.

Use autonomy as a runtime property

The same specialist can operate at A0 observation, A1 advice, A2 preparation or a narrowly controlled A3 action. Put that level in runtime policy with tool allow-lists, approval requirements, logging and rollback. Do not hide it in persona prose.

Design the handoff

A SOC triage role should hand an evidence-linked proposal to an incident owner. A control assessor should hand tested evidence and gaps to a risk owner. A red-team planner should hand an authorised evidence plan to an exercise controller. Clear handoffs reduce duplication and prevent a specialist from quietly becoming the decision authority.

Evaluate role behaviour

Test whether the role cites supplied evidence, states uncertainty, refuses out-of-scope action, escalates at the right threshold and produces the expected schema. Include adverse cases where the input asks it to exceed scope. A strong answer that violates authority is still a failed run.