Best Practices

​

Prompts

1. Be clear and outcome-oriented: Prompts should state a specific objective and define what success looks like. For Example:

   • “Classify this alert using MITRE ATT&CK and assign an escalation tier based on IOC matches.”

   • “Handle alert.” (Too vague—what does handling involve?)

2. Provide operational context: Include details about vendors, inputs, and decision criteria. For Example:
   • “Evaluate based on CrowdStrike telemetry and Okta logs.”
   • “Use the risk evaluation ability (workflow) to determine the risk level.”
3. Avoid ambiguity: State conditions explicitly to reduce variability in agent behavior. For Example:

   • “Escalate only if alert.priority is ‘High’ and the asset is tagged production.”

   • “Decide based on priority.” (Unclear what defines priority)

4. Use procedural, decision-oriented verbs: Start prompts with action words that align with decision-making, classification, or evaluation. For Example:
   • “Classify the alert…”
   • “Determine whether…”
   • “Summarize the investigation…”
   • “Evaluate the access request…”
5. Specify style and tone: Define how the agent should communicate: concise, technical, user-friendly, formal, etc. For Example:
   • “Respond with a concise, technical summary suitable for a ticket.”
   • “Summarize in plain language suitable for Slack.”
   • “Use JSON format with clear field names and short justifications.”
   • “Maintain a neutral and professional tone when declining access.”

​

Agent Configuration

​

Defining Roles

• Define responsibilities in business terms: Focus on what the agent is responsible for from an operational standpoint (e.g., “approves or denies privileged access requests based on risk”).
• Align with your security functions: Match responsibilities with real-world roles like “Access Reviewer,” “Alert Classifier,” or “Policy Auditor.”
• Keep the scope focused to simplify logic and maintenance.
• Avoid overloading: Limit the agent to a focused domain of responsibility to reduce complexity and promote maintainability.

​

Defining Constraints

• Outline what the agent should not do, by clearly defining any boundaries or constraints it must follow. This helps guide the agent’s behavior and ensures it operates within the intended limits of your environment.

​

Assigning Agent Abilities (Workflows)

1. Follow least privilege: Grant only essential workflows.
2. Validate: Use a clear and descriptive name for the workflow. Include a concise description of its purpose, and ensure all inputs and outputs are clearly defined and well-documented.
3. Group by function: Align workflows to the agent’s domain (e.g., access control, alert triage).

​

Agent Tasks

​

Defining Tasks

1. Be contextual and execution-specific: Frame the task around the specific use cases goal.

   • Good: “Evaluate if the user’s access to production servers is valid based on location, time, and group membership.”

   • Bad: “Review access.”

2. Include all relevant inputs: Reference the data the agent should use in its decision-making (e.g., alert severity, source IP, user department).
3. Use domain-specific language: Tailor the phrasing to your security or operational use case so the agent understands the terminology and logic.
4. Keep the task narrowly scoped: One task = one decision, classification, or action. Break larger objectives into separate workflow steps if needed.

1. Repeat critical instructions in the agent task (if essential) – LLMs prioritize the most recent input, so if certain guidance is crucial, it’s recommended to repeat it in the agent task, even if it’s already defined in roles or constraints, to ensure it’s followed.
2. Avoid conflicting guidance across instructions- When multiple instructions contain overlapping or contradictory information, the LLM may become confused. It is important to ensure that the agent task’s instructions reinforces or restates key rules instead of assuming the model will recall or reconcile the instructions stated in the roles and constraints section.

​

Structuring Agent Outputs

1. Define an output schema: Use consistent structures like JSON.
2. Include metadata: Capture fields like risk_level, decision_justification, or policy_violation.
3. Log identifiers: Include values like ticket_id, incident_id, or requestor.

{
  "decision": "deny",
  "risk_level": "high",
  "escalated_to": "SecOps_Tier3",
  "policy_violation": "Access requested outside approved hours"
}

​

Writing Instructions for Roles & Responsibilities vs. Tasks

1. Behavior is relevant across multiple workflows.
2. You are defining a persistent capability or policy.
3. You want to clarify what the agent is accountable for long-term.
4. Roles & Responsibilities defines the agent’s core functional purpose (e.g., “access approver,” “alert triage”).

1. You are instructing the agent for a specific decision or action.
2. Workflow inputs require custom logic.
3. You want temporary behavior overrides.