> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mcpmanager.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Cybersecurity & Threat Intelligence

> How MCP Manager lets security teams and MSSPs adopt the agentic SOC safely — one governed gateway that enforces against tool poisoning at runtime, applies least privilege to agents as first-class identities, keeps tenant data isolated, and produces the audit evidence ISO 42001, NIST AI RMF, and the EU AI Act expect.

MCP connects AI agents to the systems a security team runs: the SIEM and XDR, the threat-intel platform, ticketing and SOAR, and the internal APIs holding client telemetry. Engineers are already wiring those connections in — the agentic SOC is shipping, with ATT\&CK-tactic-driven hunts that run across live telemetry in minutes now a product category, and Gartner's 2026 top-trend list leading with agentic AI demanding cybersecurity oversight. The catch is that a security firm holds the highest trust bar in any industry, as the custodian of other organizations' telemetry, breach data, credentials, and intelligence, where for an MSSP multi-tenant isolation is existential.

## The opportunity and the bind

The irony this audience feels acutely: they are being asked to adopt internally the exact class of technology whose risks they warn the rest of the world about. The new risks arrive with the agents:

* **Prompt injection (OWASP LLM01) and MCP tool poisoning.** A poisoned tool's malicious instructions hide in tool metadata, are reviewed once at connect time, then fire silently on every invocation forever. OWASP now documents tool poisoning as a named attack class, and reporting in early 2026 found thousands of MCP servers exposed without authentication.
* **Over-privileged agents and credential sprawl.** The more an agent can do, the larger its blast radius; ungoverned MCP servers multiply credential exposure points.
* **Uncontrolled retrieval and cross-tenant exfiltration.** For an MSSP, an agent leaking one client's data into another's context is a possibly contract-ending event.
* **Audit blind spots.** Without a control point, the team cannot reconstruct who — human or agent — accessed what, when, through which tool, and why. That is the exact question their own auditors and clients ask.

The bar for "acceptable risk" here is far higher than for a normal enterprise, so the usual two options both fail: block it and fall behind competitors shipping agentic SOC capabilities, or allow it ungoverned and lose the ability to answer that audit question. MCP Manager is the third option — a runtime control plane between the agents and the servers, mediating every message in both directions without changing either side.

```mermaid theme={null}
%%{init: {'theme':'base','themeVariables':{'fontFamily':'Lato, sans-serif','lineColor':'#6a6b76','primaryColor':'#e0e2e8','primaryTextColor':'#12141d','primaryBorderColor':'#6a6b76','edgeLabelBackground':'#ffffff','textColor':'#12141d'}}}%%
flowchart LR
  A1["🤖<br/>SOC investigation & triage agents"]
  A2["🤖<br/>Threat-intel & hunting agents"]
  GW["🛡️<br/>MCP Manager gateway"]
  LOG[("🗄️<br/>Audit log")]
  subgraph est["Your security stack"]
    direction TB
    S1["🖥️<br/>SIEM / XDR"]
    S2["🖥️<br/>Threat-intel platform"]
    S3["🖥️<br/>Ticketing & SOAR"]
    S4["🖥️<br/>Internal APIs & tenant data"]
  end
  P["🚫<br/>Poisoned tool / injection"]
  A1 -->|"identity-attributed<br/>tool calls"| GW
  A2 --> GW
  GW -->|"inspected both ways"| S1
  GW --> S2
  GW --> S3
  GW --> S4
  GW -.->|"every call,<br/>every identity"| LOG
  P -.->|"blocked at runtime"| GW
  classDef gateway fill:#0086ff,color:#ffffff,stroke:#062b4c,stroke-width:2px;
  classDef client fill:#80cbc4,color:#062b4c,stroke:#00796b,stroke-width:1.5px;
  classDef server fill:#aed8ff,color:#062b4c,stroke:#0b4880,stroke-width:1.5px;
  classDef datastore fill:#062b4c,color:#ffffff,stroke:#0086ff,stroke-width:1.5px;
  classDef blocked fill:#ec9c9d,color:#12141d,stroke:#eb5757,stroke-width:2px;
  class GW gateway;
  class A1,A2 client;
  class S1,S2,S3,S4 server;
  class LOG datastore;
  class P blocked;
  style est fill:transparent,stroke:#9ca1ab,stroke-dasharray:4 3,color:#6a6b76;
```

The gateway inspects traffic in both directions at runtime — the unguarded channel attackers abuse — rather than trusting a tool that was checked once at connect time.

## The regulatory and commercial reality

Security firms carry a dense compliance load because they are both regulated entities and the parties their clients lean on to pass audits. They typically hold several frameworks at once and reuse evidence across them.

* **Established frameworks** — SOC 2 Type II, ISO/IEC 27001, FedRAMP, CMMC 2.0, the NIST catalogs (CSF, 800-53, 800-171), NYDFS Part 500, and DORA, where you reuse evidence across all of them. MCP Manager adds one reusable evidence source for AI access: a [single audit log](/security/audit-and-observability) of every agent call.
* **The emerging AI-governance stack** — the EU AI Act, the NIST AI RMF, and ISO/IEC 42001 are now a commercial gate appearing in client due-diligence questionnaires, and none was designed for agentic AI with tool access. MCP Manager is the [runtime control point and record](/security/runtime-protections) that demonstrates governance over your own AI use where those frameworks stop at models.

That gap — frameworks built for models, not for autonomous agents with tool access — is exactly what the table below maps onto.

| Their concern                                                  | What MCP Manager enforces today                                                                                                                                                                              | What to take away                                                                          |
| -------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------ |
| **Tool poisoning / prompt injection**                          | [Gateway rules](/features/gateway-rules/overview) inspecting traffic in both directions at runtime, plus [tool-change protection](/security/feature-governance) that pins a tool against post-approval edits | Enforcement at runtime, the channel attackers abuse, not only at connect time              |
| **Over-privileged agents / credential sprawl**                 | [Identity-aware access](/security/authentication-and-identity) with SSO and SCIM, per-agent identity, and per-team tool scoping                                                                              | Least privilege applied to agents as first-class identities, shrinking the blast radius    |
| **Uncontrolled retrieval / cross-tenant exfiltration**         | Inline detection (regex and Microsoft Presidio) with block, redact, mask, replace, or hash, plus org-level tenant isolation in the data model                                                                | Sensitive data is caught and stopped before it crosses a boundary                          |
| **Audit blind spots**                                          | A comprehensive audit log tying every call to the requesting identity, the tool, and the action, searchable and exportable to your SIEM                                                                      | The evidence trail auditors, regulators, and your own clients demand                       |
| **AI-governance evidence** (ISO 42001, NIST AI RMF, EU AI Act) | The control point plus the audit log are the technical and organizational measure these frameworks call for                                                                                                  | A concrete, demonstrable answer to "what is our AI seeing, and how are we controlling it?" |
| **Fail-open risk during enforcement**                          | A per-rule choice to fail closed on a detector or policy error, plus break-glass kill switches                                                                                                               | Governance that fails closed, the only acceptable behavior for this audience               |
| **LLM cost and context bloat**                                 | Per-agent tool scoping, [tool metadata filtering](/features/feature-provisioning), and per-origin rate limiting                                                                                              | Predictable token spend and a clean before/after story                                     |

The highest-resonance row for an MSSP is enforcement against tool poisoning: because the gateway inspects responses in flight, a tool that was clean at connect time and turns malicious later is caught on the call that matters.

## How MCP Manager governs security-team AI

* **Runtime enforcement, both directions.** [Gateway rules](/features/gateway-rules/overview) run on requests and responses. [Microsoft Presidio](/features/gateway-rules/presidio) and [regex](/features/gateway-rules/regex) detect sensitive data — credentials, PII, IOCs — and apply one of five actions (block, redact, replace, mask, hash) inline, each set to fail closed if you choose. [Runtime protections](/security/runtime-protections) and [tool-change protection](/security/feature-governance) stop a server from silently altering a tool after approval.
* **Agents as first-class identities.** Each [agent gets its own identity](/features/api-tokens-and-headless-agents) scoped to a gateway connection; [capability-based RBAC](/deployment/rbac-and-roles/overview) and [per-team tool scoping](/features/feature-provisioning) apply least privilege; [SSO](/enterprise/sso) and [SCIM 2.0](/enterprise/scim) tie it to your IdP. See [Authentication & identity](/security/authentication-and-identity).
* **Tenant isolation.** Every record is scoped to an organization in the data model, the foundation an MSSP needs to keep one client's telemetry out of another's context.
* **An audit trail that answers the question.** Every call records the identity, the tool, the payloads, and the verdict, searchable and exportable to your SIEM for retention under your own policy. See [Audit & observability](/security/audit-and-observability).
* **Containment.** Break-glass kill switches disable a host, connection, or identity instantly, and [real-time alerts](/features/alerts) fire on policy violations and content-filter triggers.

## Why Usercentrics

This audience will not buy governance from a vendor that does not itself look credible on governance.

MCP Manager is built by **Usercentrics**, Europe's largest consent management platform, built on GDPR from day one — a company that has spent its life as the layer deciding what data is allowed to flow, with the record to prove it. That is the exact muscle a security buyer needs, applied to a new surface. The platform runs inside Usercentrics' own audited cloud and security program — a vendor doing third-party risk review can review that posture and its certifications at the [Usercentrics trust center](https://trust.usercentrics.com/). The same company can now govern data flow across the web, apps, and the AI agents reaching into internal systems, which is a single coherent story for a buyer whose whole job is provable data control.

## Further reading

<CardGroup cols={2}>
  <Card title="Energy & Utilities" icon="bolt" href="/industries/energy-and-utilities">
    The next industry page — governed AI for critical infrastructure.
  </Card>

  <Card title="Runtime protections" icon="shield-virus" href="/security/runtime-protections">
    The MCP-specific attack classes the gateway addresses, and how each is met.
  </Card>

  <Card title="Feature governance" icon="lock" href="/security/feature-governance">
    Tool-change protection, fail-closed allowlists, and provisioning controls.
  </Card>

  <Card title="Audit & observability" icon="rectangle-list" href="/security/audit-and-observability">
    What every call records and how the evidence trail is built.
  </Card>
</CardGroup>

## External sources

<CardGroup cols={2}>
  <Card title="OWASP — MCP Tool Poisoning" icon="skull-crossbones" href="https://genai.owasp.org/resource/multi-agentic-system-threat-modeling-guide-v1-0/">
    OWASP's documentation of MCP tool poisoning and agentic threats.
  </Card>

  <Card title="OWASP Top 10 for LLM Applications" icon="list-ol" href="https://genai.owasp.org/llm-top-10/">
    Prompt injection (LLM01) and related LLM risks.
  </Card>

  <Card title="ISO/IEC 42001" icon="certificate" href="https://www.iso.org/standard/42001">
    The AI Management System standard appearing in due-diligence questionnaires.
  </Card>

  <Card title="NIST AI Risk Management Framework" icon="building-columns" href="https://www.nist.gov/itl/ai-risk-management-framework">
    The Govern, Map, Measure, Manage baseline.
  </Card>
</CardGroup>
