How to set up a 24/7 red and blue team with Nori automations, step by step

Quick answer

Put five things in place: a scope file that lists the systems you own and authorize for testing, a rules-of-engagement skill every security agent loads, a nightly cron automation for the red team, a webhook automation that wakes the blue team on each alert, and a weekly purple-team review. Both teams report in one Slack channel, findings become tickets and pull requests, and a person approves every change and anything outside scope.

What you are building

A red team attacks your systems to find weaknesses. A blue team detects and responds. Most companies get the first once a year from a pen test firm and staff the second during office hours. With Nori, both run as agent sessions that start on a schedule or a webhook, work in isolated cloud sandboxes, and report in Slack.

The setup has seven parts. Each one is a file in a repository or an automation in Nori, so all of it is reviewable.

The two halves have their own deep dives: continuous agentic red teaming and the blue-team triage and response agent.

Ground rules before you start

These rules are not optional. They are what makes this security testing and not an attack.

• Only your own systems. Every target is something your company owns or has written permission to test. Third-party SaaS, shared hosting and customer environments stay out unless the provider has agreed in writing.
• Written scope and authorization. The scope file names an owner who signed off, the dates the authorization covers, and an emergency contact.
• Staging first. The red team starts on staging. Production is added later, host by host, by a pull request the security lead approves.
• Rate limits. The scope file sets a request ceiling per host. The agent stops if error rates on the target rise.
• No destructive actions. No data deletion, no denial-of-service tests, no password changes on real accounts, no reading of real customer data beyond the minimum that proves a finding.
• A person approves anything outside scope. If the agent finds a path that leads off the list, it stops and asks in Slack.

Agents complement a certified pen test; they do not replace one where a standard or a customer contract requires it. See agentic red teaming vs pen tests vs BAS.

How to set it up, step by step

1. Create the security repository and the scope file. Add security/scope.yaml (example below). Protect it with a CODEOWNERS rule so only the security lead can approve changes.
2. Write the rules-of-engagement skill. Put it in a skillset named security-ops and publish the skillset to your Nori organization. Every security automation uses this skillset.
3. Scope the credentials. Give the red team a test account on staging and read-only cloud access. Give the blue team read access to logs and the SIEM. In Nori, attach these integrations to the security agents only, not to the whole organization.
4. Create the Slack channel. Invite Nori to #sec-agents. Add the security lead and the on-call engineer.
5. Create the nightly red-team automation. A cron automation at 02:00 that posts its run as a thread in #sec-agents.
6. Create the blue-team webhook automation. Copy its webhook URL into your SIEM or Sentry alert rule. Treat the URL as a secret.
7. Create the weekly purple-team review. A cron automation on Monday morning that reads the week's red-team threads and alert triage notes.
8. Dry-run each automation. Use Run now in the Automations page, read the thread, and tighten the scope file or skill before you let the schedule take over.

Example scope file

The scope file is the single source of truth. Agents read it at the start of every run and refuse targets that are not listed.

# security/scope.yaml
authorization:
  owner: head-of-security@example.com
  approved_on: 2026-11-02
  valid_until: 2027-02-01
  emergency_contact: '#sec-oncall'

in_scope:
  - name: staging-api
    url: https://api.staging.example.com
    type: rest-api
    openapi: services/api/openapi.yaml
    test_accounts: [redteam-a@example.com, redteam-b@example.com]
    max_requests_per_second: 5
  - name: staging-web
    url: https://app.staging.example.com
    type: web-app
    max_requests_per_second: 3
  - name: source
    repos: [example/api, example/web, example/infra]
    type: code-review

out_of_scope:
  - '*.example.com production hosts'
  - payments provider sandbox
  - identity provider tenant
  - any host not listed under in_scope

forbidden_actions:
  - denial of service or load testing
  - deleting or modifying data that the test accounts do not own
  - social engineering of staff
  - credential attacks against real user accounts

markers:
  request_header: 'X-Redteam-Run: <run id>'

reporting:
  slack_channel: '#sec-agents'
  tracker: Linear team SEC
  severity_scale: [critical, high, medium, low, info]

The markers header matters for the blue team. Every red-team request carries it, so the blue-team agent can tell authorized test traffic from a real attacker.

Example rules-of-engagement skill

A skill is a Markdown file the agent reads before it acts. Keep it short and written as orders.

---
name: rules-of-engagement
description: Use before any security testing or alert response. Sets scope, limits, stop conditions and reporting.
---

# Rules of engagement

1. Read security/scope.yaml. If today is after valid_until, stop and post in #sec-agents.
2. Test only targets under in_scope. Resolve every hostname before the first request and compare it with the list.
3. Send the X-Redteam-Run header on every request. Stay under max_requests_per_second.
4. Never perform a forbidden action. Prove a finding with the smallest request that shows it.
5. Use only the listed test accounts. Never store real customer data in notes, tickets or memory.
6. Stop conditions: the target returns 5xx on more than 5% of requests, a finding exposes real customer data, or the next step needs a target outside scope. Post what you have and wait for a person.
7. Before reporting, search shared memories for the finding. Skip known open findings and recorded false positives.
8. Report each confirmed finding with: title, severity, affected target, reproduction steps, request and response excerpts, suggested fix.
9. Fixes go in a pull request. Never merge. Never change production configuration.

Example automation definitions

Create the three automations in the Nori dashboard or from the CLI. These are the CLI definitions. The channel ID is the ID of #sec-agents.

# 1. Red team: every night at 02:00
nori-sessions triggers create \
  --name 'Red team nightly' \
  --type cron --cron-schedule '0 2 * * *' --timezone America/New_York \
  --skillset security-ops \
  --slack-channel-id C0SECAGENTS \
  --prompt 'Follow the rules-of-engagement skill. Run the nightly red-team pass against every in_scope target in security/scope.yaml. Retest open SEC tickets first. For each new confirmed finding, create a Linear ticket in team SEC and, where the fix is in our code, open a draft pull request. Finish with a summary: tested, new findings, retests passed, retests failed.'

# 2. Blue team: on every alert
nori-sessions triggers create \
  --name 'Blue team alert triage' \
  --type webhook \
  --skillset security-ops \
  --slack-channel-id C0SECAGENTS \
  --prompt 'Follow the rules-of-engagement skill. Triage the alert in the payload. Pull related logs for 30 minutes either side. Label it true positive, false positive or authorized test (X-Redteam-Run header present). Write a timeline and a recommended response. If a detection rule needs tuning, open a pull request in example/detections. Do not block, disable or delete anything.'

# 3. Purple team: Mondays at 09:00
nori-sessions triggers create \
  --name 'Purple team weekly review' \
  --type cron --cron-schedule '0 9 * * 1' --timezone America/New_York \
  --skillset security-ops \
  --slack-channel-id C0SECAGENTS \
  --prompt 'Compare last week: list each red-team technique that ran and whether an alert fired for it. For each gap, draft a detection rule pull request. List findings older than 14 days with no fix merged. Save new false-positive patterns to shared memories.'

Nori wraps a webhook payload as untrusted data before the agent sees it, so text inside an alert cannot give the agent new orders. Changes to an automation made by a non-admin wait for an admin to approve them.

Where findings land and who approves

A morning in the channel looks like this:

Red team nightly  02:00
  Tested 3 targets, 412 requests. 1 new finding, 2 retests passed.
  NEW  SEC-212 (high) Invoice API returns other tenants' invoices
       Fix PR: example/api#1841 (draft)
  PASS SEC-198 Missing rate limit on password reset
  PASS SEC-203 Verbose stack trace on /api/v1/import

Blue team alert triage  02:07
  Alert: auth-failed-burst on staging-api
  Label: authorized test (X-Redteam-Run: rt-2026-11-11)
  No action needed. Detection fired within 2 minutes of the first request.

The findings memory closes the loop. When the security lead marks a finding as accepted risk, the agent saves that to shared memories, and no later run reports it again.

Frequently asked questions