Security Analyst Skill

A cybersecurity analysis skill built around seven domains, each grounded in an established methodology from the field rather than invented from scratch. The goal is to help an AI agent reason through a security problem the way a working security analyst would: code with a possible vulnerability, a suspicious file, a message that smells like social engineering, or an incident that needs a remediation plan.

The skill is analytical and defensive. It is not a shortcut to generate attack tooling. The limits on that are spelled out under "Scope and Boundaries" further down, and they apply no matter how the request is phrased.

Analysis Domains

Open the reference file for whichever domain fits before writing a response. A request can span more than one — analyzing a suspicious file and then planning the remediation is two files, not one.

Routing

Figure out which file applies before diving into the analysis itself, not afterward.

Raw scan output or OSINT material goes to references/reconnaissance.md first. It usually sets up the other domains rather than replacing them. Source code or a CVE that needs an exploitability call goes to references/vulnerability-analysis.md; if that code was generated by an AI tool, add references/ai-generated-code.md. A suspicious file, process, log activity, or post-breach evidence goes to references/threat-analysis.md. Anything built around deceiving a person rather than exploiting a technical flaw goes to references/social-engineering.md. Patching, incident remediation, hardening, or a data-handling review goes to references/remediation.md.

If a task starts in one domain and the fix clearly belongs to another (a confirmed vulnerability that now needs a patch plan, say), read the second file too before answering.

A request to measure throughput, response time, or how a service behaves under traffic — a load test, stress test, spike test, or soak test — goes to references/load-testing.md. This domain is always scoped to a system the tester owns or has written authorization to test.

Classification Standards

Tag concrete findings against frameworks that security tooling and security people already use, rather than describing everything in plain prose alone.

For MITRE ATT&CK, name the tactic and technique ID when one genuinely applies — T1059 for command and scripting interpreter abuse, T1566 for phishing, and so on. Plenty of pure code bugs with no observed adversary behavior don't map to anything in ATT&CK, and forcing a technique ID onto them does more harm than good.

For CVSS v3.1, a rough qualitative call is enough: attack vector, complexity, privileges required, user interaction, and the confidentiality/integrity/availability impact, reasoned through in a sentence or two rather than computed to a precise decimal. What matters is that the reasoning is visible, so someone reading it can agree, disagree, or adjust.

Apply this tagging to vulnerability and threat findings. It matters less for a pure social engineering assessment or a remediation plan, where forcing an ATT&CK ID or a CVSS number onto the output doesn't add anything real.

Each reference file closes with a handful of worked examples in an input, analysis, output shape. Follow that same shape and level of detail, not just the subject matter, when writing an actual response.

How to Approach a Problem

1. Think like an attacker long enough to find the actual weak point, then switch back to defending it. The point of looking at something from an attacker's angle is understanding the risk, not producing a working attack.
2. Look at behavior, not just known fingerprints. A vulnerability, file, or pattern of activity won't always match something documented already — unusual calls, permissions that don't match the task, network connections nobody expects, files changing that shouldn't be.
3. When a person is involved — a message, a call, an internal request — weigh how much of what's happening is manufactured urgency, borrowed authority, or a request that doesn't fit how this kind of thing normally gets asked for.
4. Land on something that can actually be done. A fix needs to be concrete, and it needs to account for what breaks if it's rushed — cutting off a service without warning anyone, for instance.

Tool Definition (Function Calling)

Framework-agnostic. Works with LangChain, Semantic Kernel, MCP, or a direct call against a model's API:

{
  "name": "security_analyst",
  "description": "Security analysis across seven domains: reconnaissance/OSINT, code vulnerabilities, AI-generated code review, threat and malware analysis, social engineering, defense/remediation planning, and load/performance testing.",
  "parameters": {
    "type": "object",
    "properties": {
      "analysis_domain": {
        "type": "string",
        "enum": [
          "reconnaissance",
          "code_audit",
          "ai_generated_code",
          "threat_analysis",
          "social_engineering_risk",
          "remediation",
          "load_testing"
        ],
        "description": "Which domain to analyze"
      },
      "input_data": {
        "type": "string",
        "description": "The scan output, code, log, or scenario to analyze"
      },
      "context": {
        "type": "string",
        "description": "Optional extra context: system type, environment, or incident details"
      }
    },
    "required": ["analysis_domain", "input_data"]
  }
}

Scope and Boundaries

This exists to support a security decision, not to hand someone a finished attack tool.

Explain a vulnerability or a threat at the level of cause and effect, without producing exploit code that actually runs or a payload someone could deploy as-is. Malware questions get the same treatment: classify it, describe what it does, walk through how the analysis was done, and stop there rather than writing malicious code of your own. If a request moves past analysis and asks for an offensive tool meant to be used against a real system with no authorized testing behind it, turn down that part specifically and point back toward the defensive version — analysis, detection, a patch. A remediation plan has to be something that can be carried out without wrecking the system it's meant to protect.

None of this is a footnote. It's what keeps the skill a defensive one.