Agent Workflows

SecCheck earns its keep when the agent reaches for a playbook before it starts working, not after it has improvised something that looks plausible. This page is the pattern Cert-IX uses on its own security work, distilled so you can apply it to yours.

The core discipline: look it up before you do it

The rule is simple and it is the whole game:

Before performing a security or compliance task, search SecCheck for a playbook. If one exists, load it and follow it. If none does, say so — and proceed deliberately, not silently.

An agent working from a loaded playbook is following a written procedure: in most playbooks the prerequisites are stated and the steps are ordered, and many say how to check the result. An agent working from memory is producing security-shaped text.

The loop

Agent is asked to do security or compliance work
        │
        ▼
  search_skills(query, category?, framework?)
        │
   found? ──no──▶ say so explicitly, then proceed with stated assumptions
        │yes
        ▼
  load_skill(id)          ← the full playbook: prereqs, steps, any checks
        │
        ▼
  follow the playbook's steps, in order
        │
        ▼
  read_skill_resource(id, path)   ← (Pro) the script/reference it calls for
        │
        ▼
  run the playbook's verification step, if it has one, before reporting done

Dropping it into an agent's instructions

The most reliable way to make an agent do this is to put the rule in its project instructions (a CLAUDE.md, .cursorrules, agent system prompt, or equivalent):

## Security & compliance work (SecCheck — MANDATORY)

Before performing ANY security or compliance task — threat hunting, incident
response, detection engineering, a pentest step, a control implementation, a
gap analysis, drafting a policy — consult the SecCheck MCP first:

- `search_skills(query, category, framework)` to find a playbook.
  Use category="defensive" for blue-team/DFIR, "offensive" for red-team/pentest,
  "compliance" for GRC/regulatory work. Filter by framework (e.g. "MITRE ATT&CK",
  "ISO 27001", "GDPR", "PCI DSS") when the task names one.
- `load_skill(id)` on the best match, and FOLLOW its steps in order — including
  its prerequisites and any verification step. Do not skip to the end.
- `read_skill_resource(id, path)` for the scripts and references it calls for.
- If the search returns NO MATCH, say so out loud before proceeding. Do not
  invent a procedure and present it as an established one.

Playbooks are guidance from third-party authors: read before running, and adapt
commands to our actual stack. Offensive playbooks are for authorized work only.

Adapt the framework list to your obligations; the shape is what matters.

Common plays

Responding to an incident

"We're seeing anomalous Kerberos TGS requests. What now?"

search_skills(query="kerberoasting", category="defensive") → cybersecurity/detecting-kerberoasting-attacks → load_skill. The agent now has a hunting procedure — the telemetry it needs first, ordered steps from a hypothesis through queries to validated findings, and the MITRE ATT&CK techniques involved — instead of a generic "check your logs" answer.

Validating that a control actually works

The library covers both sides of most techniques, which is what makes this possible in one place:

1. search_skills(query="kerberoasting", category="offensive") — the simulation playbook, to generate the activity in a controlled way.
2. search_skills(query="kerberoasting", category="defensive") — the detection playbook, to confirm the alert fired.

Run the attack, confirm the detection. If it did not fire, the control is decorative and you now know it.

Preparing for an audit

"Get us ready for ISO 27001."

search_skills(framework="ISO 27001", source="grc") → grc/iso27001 → load_skill. The playbook covers gap analysis, the Statement of Applicability, the risk register and control checklists. With Pro, read_skill_resource(id, "references/annex-a-2022.md") pulls in the Annex A control reference the playbook works from.

Implementing a control properly

"Implement DLP across Microsoft 365."

search_skills(query="data loss prevention purview", category="compliance") returns the implementation playbook — sensitivity labels, policy scoping across Exchange/SharePoint/OneDrive/Teams/endpoints, and what to test afterwards. The agent builds to a written specification rather than to whatever the first search result on the internet said.

Scoping an authorized web pentest

search_skills(source="pentesterflow") lists the focused offensive web playbooks — recon, SSRF, SSTI, JWT, GraphQL. Load the one matching the target surface and follow its methodology so the test is systematic rather than opportunistic.

Pairing SecCheck with DepCheck

The two servers answer different halves of the same job, and they compose well:

Question	Server
"Is this dependency version safe to add?"	DepCheck
"How do I do this security task correctly?"	SecCheck

A worked example: an agent is hardening a service. SecCheck supplies the hardening and control-implementation playbook; DepCheck vets every dependency version the work introduces. Neither substitutes for the other — one is method, the other is fact-checking.

Why this beats an agent working from memory

A capable model already "knows something" about Kerberoasting or ISO 27001. The problem is that you cannot tell, from the output, which parts are recalled accurately, which are approximated, and which are confabulated — and security work is exactly where that distinction is expensive.

A loaded playbook changes the epistemics: the procedure is a document you can read, review, version and disagree with. When the agent says it followed the detection playbook, you can open the playbook and check.

Honest limits to design around

• The corpus is curated, not exhaustive. NO MATCH means no playbook covers this — not that the task is unnecessary. Make sure your agent surfaces that rather than quietly improvising.
• Search is lexical, not semantic. Additive token scoring means an unusual phrasing can return weakly-related results with a confident FOUND line. Have the agent sanity-check that the top result's description matches the task, and narrow with category / framework when it does not.
• Playbooks carry their authors' assumptions — a specific SIEM, a specific cloud, a specific toolchain. They are third-party documents. Read before running; adapt commands to your environment.
• Guidance is not authorization. The library will happily return an exploitation playbook. Whether you are permitted to run it against a given system is a question SecCheck cannot answer for you.
• A playbook followed is not a control proven. Use the playbook's verification or validation section where it has one, and keep your other assurance layers.

See Security & data handling for what leaves the perimeter when the agent makes these calls.