Notifications
Clear all
Topic starter
02/08/2026 11:51 am
TL;DR: MCP can replace brittle point-to-point integrations with a standard interface for AI SOC agents, enabling natural-language detection engineering, alert triage, and cross-platform orchestration across tools such as SIEMs and threat intelligence platforms, according to Panther. The practical issue is not whether AI can help, but which authentication, approval, and blast-radius controls still hold when agents act through shared interfaces.
NHIMG editorial — based on content published by Panther: MCP Tools for Security Teams, Using the MCP Ecosystem to Orchestrate AI SOC Agents
By the numbers:
- With 15 security tools, that's 105 potential integration points to maintain.
Questions worth separating out
Q: How should security teams govern AI agents that use service accounts and MCP tools?
A: Start with ownership, then add runtime attribution and containment.
Q: Why do MCP servers create new identity governance challenges for IAM teams?
A: Because the server often becomes part of the authorisation path, not just the application path.
Q: What breaks when AI assistants can query and act on security data through a shared protocol?
A: What breaks is the assumption that access stays narrow and task-specific.
Practitioner guidance
- Classify MCP servers as privileged identities Assign each MCP server a named owner, a documented business purpose, and a reviewed permission scope.
- Scope AI access to read-only first Start with investigative and query-only use cases before allowing rule changes, ticket updates, or response actions.
- Map every MCP action to an approval boundary Define which tool calls are always safe, which require human approval, and which are blocked entirely.
What's in the full article
Panther's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of MCP server setup across Panther, Splunk, Elastic, and Chronicle
- Practical authentication differences between token-based access and OAuth or SSO-based deployments
- Concrete workflows for detection engineering, alert triage, and investigation inside specific SOC tools
- Implementation tradeoffs for teams deciding whether to pilot MCP in read-only mode or expand into execution
👉 Read Panther's guide to MCP tools for orchestrating AI SOC agents →
MCP tools for AI SOC agents: are your security workflows ready?
Explore further
02/08/2026 1:00 pm
MCP does not remove the identity problem, it relocates it. The protocol standardises how AI reaches tools, but it does not decide who owns those capabilities, how long access persists, or what the agent is allowed to do with them. That means security teams are still responsible for scoping, attribution, and revocation, only now the control surface is a server that can expose many tools at once. Practitioners should treat MCP as an identity governance layer, not just an integration pattern.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
A question worth separating out:
Q: Who should approve MCP-connected actions in security operations workflows?
A: Humans should approve any MCP-connected action that changes detections, alters response workflows, or exports sensitive data outside the investigation boundary. Read-only investigation can often be delegated earlier, but execution needs an accountable operator. The approval model should be based on action sensitivity, not on whether the request came from an AI assistant.
👉 Read our full editorial: MCP tools change how security teams orchestrate AI SOC agents
