The thesis
MCP and agentic toolchains industrialize the handoff between reasoning and action. They do not change the TLCTC universe of cyber threats.
1. MCP is infrastructure
It standardizes how AI applications connect to tools, resources, and prompts. It is an invocation and context-exchange layer, not a threat cluster.
2. Agents are orchestrators
They select, sequence, retry, and adapt tool calls. This changes velocity and reach, not the underlying cause taxonomy.
3. Actions classify
TLCTC classifies the atomic action by the generic vulnerability exercised: function scope, code flaw, identity artifact, path position, finite capacity, FEC execution, and so on.
MCP agents are capability and velocity amplifiers for existing TLCTC attack paths. They are not new top-level cyber threat clusters.
TLCTC ground rules
Before mapping MCP, agents, HexStrike, or BOAZ-style payload tooling, the TLCTC grammar must be kept strict.
| Rule | Meaning for MCP / agents | Classification effect |
|---|---|---|
| Axiom III | Threats are causes, not outcomes. | “Agentic attack,” “ransomware,” “data breach,” “privilege escalation,” and “lateral movement” are not clusters. |
| Axiom IV | Threats are not actors. | An AI agent, red-team operator, or named group is not the classification unit. |
| Axiom VI | One step = one generic vulnerability = one cluster. | Each tool call or effect-producing action must be decomposed into atomic steps. |
| Axiom VII | Vector is defined by the initial generic vulnerability. | Classify by what is first abused or exploited, not by the workflow label. |
| Axiom X / R-CRED | Credential acquisition and credential application are different. | Acquisition maps to the enabling cluster + [DRE: C]; using credentials is always #4. |
| R-EXEC | If Foreign Executable Content executes, record #7. | Tool invocation and payload execution must not be collapsed. |
| R-SUPPLY | Supply chain is anchored at the Trust Acceptance Event. | An MCP server, plugin, package, or tool becomes #10 only when third-party trust is accepted and leveraged. |
What MCP changes
The Model Context Protocol is an open protocol for integrating LLM applications with external data sources and tools. Its architecture uses hosts, clients, and servers; servers expose resources, prompts, and tools, while hosts coordinate clients and security decisions. Tools can be discovered and invoked by language models, with the MCP specification recommending visible tool exposure, invocation indicators, and human denial/approval paths for trust and safety.
In TLCTC terms, this is not one threat. It is a routing surface for actions. The same protocol can be used to query a database, list files, call a scanner, invoke a cloud API, run a command, or produce a report. Classification only starts once a concrete action exercises a generic vulnerability.
“Model-controlled tool invocation” is not a cluster. The cluster depends on the function invoked, the target role, whether a flaw is triggered, whether credentials are presented, whether FEC executes, and whether a trust boundary is accepted.
Where classification happens
The MCP or agent label is the wrong classification level. The TLCTC unit is the atomic action.
| Observed action | TLCTC cluster | Why |
|---|---|---|
| Agent invokes a legitimate API, CLI, admin function, scanner, or interpreter in a way that exceeds intended scope. | #1 Abuse of Functions | The generic vulnerability is functional scope, trust, and designed capability. No implementation flaw is required. |
| Agent triggers a flaw in server-role software using crafted input or requests. | #2 Exploiting Server | The vulnerable component accepts and handles inbound stimuli relative to the attacker. |
| Agent triggers a flaw in client-role software through crafted content, file, response, or state. | #3 Exploiting Client | The vulnerable component consumes attacker-controlled content or response data. |
| Agent presents a password, token, key, API secret, session cookie, or equivalent identity artifact. | #4 Identity Theft | Credential use/application is always #4. Acquisition is classified separately. |
| Agent exploits a controlled communication-path position to intercept, modify, inject, downgrade, or replay. | #5 Man in the Middle | #5 begins after the path position is controlled. Gaining the position is another cluster. |
| Agent exhausts finite bandwidth, CPU, memory, queue, quota, thread pool, API limit, or storage capacity by volume/intensity. | #6 Flooding Attack | The generic vulnerability is finite capacity. If a crash is caused by a flaw, use #2/#3 instead. |
| Agent causes attacker-controlled executable content, script, module, macro, shellcode, or interpreter-fed command to execute. | #7 Malware | The environment’s designed execution capability is exercised. R-EXEC requires #7 when FEC runs. |
| Agent persuades a human to approve, reveal, install, transfer, or change behavior. | #9 Social Engineering | The exploited generic vulnerability is human psychology. Later technical actions classify separately. |
| Organization accepts a third-party MCP server, plugin, package, model extension, update, or hosted tool as trusted. | #10 Supply Chain Attack | The cluster is anchored at the Trust Acceptance Event, not at ordinary use of third-party code after acceptance. |
Tooling category translation
Operator vocabulary organizes by workflow: initial access, execution, persistence, lateral movement, privilege escalation, C2, exfiltration. TLCTC organizes by cause. The same vocabulary must therefore be translated before it can be used for threat classification.
| Operator category | TLCTC status | Resolves to | Key correction |
|---|---|---|---|
| C2 / implant frameworks | Decomposes into clusters | #1 → #7 | Protocol use, tasking, and legitimate execution surfaces are #1; foreign code execution is #7. |
| Initial access / loaders | Position, not cluster | Vector-dependent: #9 / #2 / #3 → #7 | “Initial access” names where in the story the step occurs, not what generic vulnerability is exercised. |
| Credential modules | Splits across clusters | Acquisition = enabling cluster + [DRE: C]; application = #4 |
Credential access is not automatically #4. Credential use is #4. |
| Recon / enumeration | Usually pre-SRE metadata | no cluster by itself | Observation alone does not necessarily exercise a TLCTC generic vulnerability. |
| Lateral movement | Sequence descriptor | (#4 → #1) × N | Classify the nodes; annotate the movement shape. |
| Privilege escalation | Outcome / trust-boundary effect | Technique-dependent: #1 / #2 / #3 / #7 | The elevation result is not the cause-side cluster. |
| Payload evasion / obfuscation | Capability modifier | Usually supports #7, sometimes enabled by #1 | Evasion is not a TLCTC cluster. Execution of FEC is. |
| Exfiltration | Outcome / data movement label | Cause-dependent + [DRE: C] |
Loss of confidentiality is a Data Risk Event, not a threat cluster. |
HexStrike / BOAZ as a capability overlay
HexStrike-style MCP red-team suites and BOAZ-style payload layers are best read as actor-capability overlays. They bundle tools, agents, decision support, and payload handling. The repository label does not classify as a threat; the actions performed through it do.
Public repository descriptions claim MCP-enabled AI agents, large security-tool arsenals, autonomous agent roles, vulnerability intelligence, exploit-generation workflows, and BOAZ payload-evasion integration with loader and encoder counts. These claims are treated as potential capability surface, not proof of real-world actor capability.
Capability vector
The vector below scores potential coverage, not observed malicious proficiency. Under TLCTC, capability is stronger when supported by classified attack-path evidence.
| Cluster | Capability signal | Potential | TLCTC caveat |
|---|---|---|---|
| #1 | Tool/API/CLI orchestration, cloud and admin-tool workflows, scanner execution, interpreter invocation. | Only #1 when legitimate functionality is misused without requiring a flaw. | |
| #2 | Web/app/API vulnerability tooling, scanner templates, exploit-generation workflows, server-side testing. | Requires triggering an implementation flaw in server-role software. | |
| #3 | Binary analysis, exploit development, crafted-content research. | Only #3 when client-role software consumes attacker-controlled content/state. | |
| #4 | Password/auth tooling, token/secret discovery, remote login or session use workflows. | Credential acquisition is enabling cluster + DRE:C; credential application is #4. | |
| #5 | Responder/proxy/TLS-style flows, traffic-position exploitation support. | Gaining the path position is not #5; exploiting it is. | |
| #6 | High-speed scanning can create load; dedicated flooding is less central. | #6 requires capacity exhaustion as the mechanism, not merely noisy reconnaissance. | |
| #7 | Payload generation/wrapping, loaders, encoders, obfuscation, process execution support. | Payload tooling is not #7 until FEC executes. R-EXEC then requires #7. | |
| #8 | No visible physical-access capability from the described software stack. | Physical interaction with hardware/facilities would be separate. | |
| #9 | OSINT and prompting patterns may support lures, but human manipulation is not central in the tooling claim. | #9 requires psychological manipulation of a human. | |
| #10 | MCP servers, plugins, packages, and tool registries can become trust inputs. | Only #10 at the Trust Acceptance Event. Ordinary use of a known third-party tool is not automatically #10. |
Capability radar
The same potential-coverage vector, drawn across all ten clusters. Scores reflect potential coverage, not observed proficiency — the chart visualizes the table above, nothing more.
Attack-path archetypes
Agentic tooling mostly changes the ease and speed of chaining. The TLCTC path stays cause-oriented.
Server flaw to tool execution
Exploit server-role flaw, execute FEC, use credentials, then abuse legitimate admin or remote-execution functions.
C2 / implant behavior
Legitimate protocol/tasking/execution surface first; foreign executable content runs second.
Credential-led expansion
Secrets obtained by abusing functions; then presented to authenticate; then used to operate legitimate functions.
Lateral movement shape
Repeated credential application and remote/admin-function abuse across hosts or services.
Velocity compression
Agentic orchestration does not add a node. It compresses the edges.
The clusters did not change. The Δt values changed. This is the strategic risk shift: less time for detection, triage, containment, and human approval.
Bow-Tie separation
TLCTC keeps three lanes separate: causes, data risk events, and business consequences. MCP/agents belong in Lane 1 only when their actions exercise a generic vulnerability.
- #2 server flaw exploitation
- #7 FEC execution
- #4 credential use
- #1 function abuse
+ [DRE: C]secret or data exposure+ [DRE: I]unauthorized modification+ [DRE: Ac]data present but unusable- Business impact: reporting, loss, downtime, churn
Notice the grammar: DREs are appended with + [DRE: X]. They are never standalone threat clusters and should not be written as a next arrow-step.
Control implications
There is no single “MCP control.” Controls must map to the cause-side cluster being exercised. A control that prevents one cluster may only limit consequences for another.
| Cluster | Preventive control logic | Detection / governance logic |
|---|---|---|
| #1 Abuse of Functions | Least-privilege tool exposure, allowlisted MCP tools, approval gates for destructive calls, safe defaults, scoped API permissions. | Log every tool call with actor, prompt context, arguments, resource scope, and approval state. |
| #2 Exploiting Server | Input validation, secure coding, patching, WAF where appropriate, service isolation, rate and schema constraints. | Correlate agent-originated requests with server errors, exploit signatures, unusual payload patterns, and vulnerability scanner output. |
| #3 Exploiting Client | Sandbox content handlers, patch clients, harden parsers, restrict file and URL handling by agents. | Monitor client crashes, sandbox escapes, unusual document/script execution, and cross-boundary content flows. |
| #4 Identity Theft | Short-lived tokens, scoped credentials, strong binding of agent identity to human approval, no ambient secrets in MCP context. | Detect unusual token use, impossible travel, abnormal tool-to-resource combinations, and agent use of human credentials. |
| #5 Man in the Middle | End-to-end TLS, certificate validation, pinning where appropriate, trusted proxy controls, no silent trust-anchor installation. | Watch certificate changes, downgrade attempts, proxy anomalies, DNS redirection, and unexpected interception points. |
| #6 Flooding Attack | Quotas, rate limits, job budgets, concurrency caps, circuit breakers, scan throttling, sandboxed test ranges. | Track resource exhaustion, queue growth, API limit hits, cloud cost spikes, and agent retry storms. |
| #7 Malware | Execution allowlists, signing, sandboxing, interpreter restrictions, egress control, no unchecked generated binaries. | Detect foreign executable content, process injection indicators, unusual interpreter chains, and unsigned or newly generated artifacts. |
| #10 Supply Chain Attack | Server admission controls, signed MCP server manifests, trusted registries, dependency review, tool allowlisting at onboarding. | Audit MCP server changes, tool-list changes, package provenance, update paths, and trust decisions at the TAE. |
Blocking “AI agents” as a category is too coarse. The precise question is which generic vulnerabilities the agent can exercise and whether the control prevents the cause or merely detects the consequence.
Analyst checklist
Use this checklist to keep MCP/agent assessments TLCTC-clean.
Classification questions
What atomic action occurred? Did it require a code flaw? Was the vulnerable component server-role or client-role? Was a credential acquired or applied? Did FEC execute? Was a human manipulated? Was third-party trust accepted?
Evidence questions
Is this capability merely listed in a tool, or observed in a real path? What logs show the tool call, credential use, execution event, DRE, and time between steps?
Final formulation
MCP and agents do not redefine cyber threats. They compress and automate the path between existing TLCTC clusters. The stable classification remains: one step, one generic vulnerability, one cluster — with Data Risk Events and business consequences recorded separately.
Sources and notes
The article uses TLCTC v2.1 semantics, the uploaded “Tooling Categories → TLCTC Anchors” taxonomy, and public protocol/repository descriptions as source material. Public repository claims are treated as capability-surface claims, not proof of operational actor maturity.
-
Model Context Protocol — Architecture Host/client/server architecture, security boundaries, server capabilities.
-
Model Context Protocol — Tools Tools exposed by servers, model-controlled discovery/invocation, human-in-the-loop guidance.
-
HexStrike AI MCP Agents Public README claims for MCP-enabled AI security automation, tools, agents, and workflow categories.
-
Yenn503 / Hexstrike-redteam Public fork integrating HexStrike-style MCP automation with BOAZ-style payload tooling.
-
Yenn503 / BOAZ-MCP Public README claims for MCP wrapping of BOAZ payload tooling.
-
Local uploaded source:
tooling-categories-tlctc.htmlConceptual translation of offensive tooling categories into TLCTC anchors.
Generated as a self-contained HTML briefing page.