The Model Context Protocol (MCP) lets AI agents query your logs and security data directly — a huge productivity win, and a new attack surface. Connecting an agent to sensitive data raises real risks: prompt injection, tool poisoning, and over-broad permissions. This guide explains what MCP is, why it matters for security data, where the danger is, and how to connect agents safely.
What is the Model Context Protocol (MCP)?
MCP is an open protocol that standardises how AI agents connect to external tools and data. Instead of scraping a UI or hand- writing queries, an agent connects to an MCP server, discovers a catalog of typed tools, and calls them to read data or take actions. It is becoming the common interface between agents (Claude Code, Cursor, Codex, and others) and the systems they work with.
Why MCP matters for logs and security data
For engineering and security teams, MCP means an analyst or developer can investigate logs, triage security, and build connectors from the agent they already use — without leaving their editor or exporting data. The agent calls typed tools (search logs, list notables, look up an IOC) that run inside the platform, so answers are fast, consistent, governed, and tenant-scoped, rather than the agent guessing from scraped screens.
The security risks of MCP
Pointing an autonomous agent at your data introduces failure modes that traditional integrations do not have:
- Prompt injection — malicious instructions hidden in data the agent reads (including your own logs) try to hijack its behaviour.
- Tool poisoning — malicious instructions embedded in a tool's metadata or description, so the agent is manipulated through a trusted interface.
- Resource / context poisoning — hidden instructions planted in data sources or shared state that propagate to the agent as trusted information.
- Excessive permissions — an over-scoped token or write-capable tool turns a compromised or confused agent into real damage.
The core principle
Treat everything the agent reads — log lines included — as data, not instructions, and give the agent the least privilege it needs. Most MCP incidents come down to one of those two principles being broken.
How to connect agents to security data safely
- Read-only by default. Writes should be an explicit, narrow, opt-in allowlist — not the baseline.
- Scoped, authenticated access. Per-token, capability-level scopes and authenticated connections (PAT or OAuth) so each agent sees only what it should.
- Enforce existing RBAC. The agent should inherit the user's permissions, not bypass them.
- Gateway, rate-limit, and audit. Route through a controlled endpoint, cap call rates, and log every call for review.
- Approval workflows for change. Any action that modifies your environment should create a draft for human approval, not apply directly.
- Treat tool output as data. Guard against instructions smuggled through retrieved content.
How LogPulse secures MCP access
LogPulse ships a remote MCP server built on these principles. It is a single HTTPS endpoint authenticated by a scoped personal access token or OAuth 2.1. Tools are read-only by default, scoped per token (logs:read, siem:read, services:read, entities:read), and the only writes are opt-in propose scopes that queue a detection, rule, service, KPI or pipeline as a disabled draft for human approval — nothing is applied directly.
Every call is bound by the token holder's namespace RBAC, rate-limited and written to the audit log, and tool output is treated as data, not instructions, to guard against prompt injection through logs. Abnormal call volume or an agent write even raises a notable. Data stays EU-hosted. See the MCP server page and the MCP documentation for the endpoint, scopes, and full tool catalog — and what is an agentic SOC for how this powers AI investigation with a human in the loop.