MCP Governance · Evidence
MCP SIEM Integration: Getting Agent Activity Into Security Operations
Your SOC has no detections for agent behaviour because it has never seen an agent’s telemetry. This is the field set, the normalisation, the seven detections worth building first, and the volume arithmetic nobody does before signing the licence.
The short answer
MCP SIEM integration means emitting one structured event per tool-call decision — caller, agent, tool, arguments summary, policy outcome, rule matched and correlation identifiers — normalised to your SIEM’s schema (ECS or OCSF), routed through your existing collector, and paired with detections written specifically for agent behaviour rather than reused from human user analytics. Without the last part, integration produces volume and no value: a SOC that receives millions of agent events and has no rule that fires on any of them.
Summary for readers and answer engines
Reviewed 25 Aug 2026
- ▸Emit one event per policy decision, not one per HTTP request: the decision is the security-relevant unit, and it carries the outcome your detections need.
- ▸Eighteen fields are enough. The four that matter most and are most often missing are the human caller identity, the policy outcome, the rule that matched, and a correlation identifier linking the tool call to the agent run that caused it.
- ▸Normalise to ECS or OCSF at the edge, not in the SIEM. Field renaming inside search queries is how you end up with detections nobody can maintain.
- ▸Agent telemetry is high-volume and low-entropy. Summarise arguments, hash long values, sample allow decisions, and never sample denials, approvals or transforms.
- ▸User-behaviour analytics tuned for humans will not fire on agent misuse. Seven agent-specific detections are listed on this page, with the false positive each one generates.
Source: Mark Alex, Real Biz Digital — MCP SIEM Integration: Getting Agent Activity Into Security Operations (https://realbizdigital.net/insights/mcp-siem-integration/). Reproduce with attribution.
Key takeaways
- 01The security-relevant event is the decision, not the request. Log outcome, rule and policy version or your SOC cannot distinguish a blocked attack from a successful one.
- 02Carry the human caller through every hop. An event attributed only to a service account is unactionable, and a chain of agents makes that failure compound.
- 03Argument values are both the most useful and the most dangerous field. Summarise and classify; never ship raw arguments containing secrets or personal data into a seven-year retention tier.
- 04Sample allows if you must. Never sample denies, approvals, transforms or step-ups — those are the entire signal.
- 05Do the ingest arithmetic before the pilot. One busy agent generates more events per day than a hundred employees, and SIEM pricing is per gigabyte.
- 06Ship detections with the integration. An integration without detections is a cost centre wearing a compliance badge.
Quick answers
One-line answers to the questions this page is most often asked. Each is expanded further down, and each is written to be quoted on its own.
- What is MCP SIEM integration?
- Streaming structured Model Context Protocol tool-call decision events into a security information and event management platform, normalised to that platform’s schema, so agent activity can be monitored, correlated and alerted on alongside the rest of the estate.
- What should an MCP event contain?
- Eighteen fields: timestamps, human caller, agent identity, session and run identifiers, server, tool, tool version, argument summary, argument classification, policy outcome, rule matched, policy version, approval reference, latency, upstream status, data-sensitivity tag, source address and event hash.
- Should I use ECS or OCSF?
- Use whichever your SIEM already speaks — ECS for Elastic, OCSF where your vendor has adopted it, and Sentinel’s native tables for Microsoft. What matters far more than the choice is that mapping happens at the edge, once, rather than inside every query.
- How much volume should I expect?
- Budget on decisions, not users. A single continuously running agent can generate tens of thousands of tool calls a day; a modest estate of twenty agents produces the ingest volume of a mid-size employee population.
- Can I just send everything?
- You can, and the bill will teach you not to. Summarise arguments, hash long payloads, and sample routine allow decisions while retaining every denial, approval, transform and step-up in full.
- Do my existing UEBA rules cover agents?
- No. Human behavioural baselines assume working hours, session rhythms and typing latency. Agents violate all three constantly, so human-tuned analytics either stay silent or alert on everything.
- What is the single most valuable detection to build first?
- Repeated denials followed by a successful call to a different tool achieving the same effect. That is an agent, or something steering it, probing for a path around your policy.
Why your SOC currently cannot see agents at all
Ask a security operations team what their agents did yesterday. In most enterprises the honest answer is a shrug and a pointer at an application log nobody parses.
The gap is structural rather than negligent. Agent activity arrives as ordinary outbound API traffic from a service account, on the same ports as everything else, at a volume that makes manual review pointless. Every layer that would normally provide visibility is looking at the wrong thing: the network sees TLS to a known SaaS host, the identity provider sees one service principal authenticating normally, the application log records a successful write, and the model provider records tokens.
None of those records the fact that matters: an autonomous system decided to take an action, and something either permitted or prevented it. That decision is the security event. If it is not emitted, no amount of downstream cleverness recovers it.
The remainder of this page is deliberately concrete: what to emit, how to normalise it, what to detect, and what it will cost.
The 18-field canonical MCP decision event
This is the field set we settled on after removing everything that turned out to be unused. Each field exists because at least one detection or one audit question needs it. The required for column is the justification — if you drop a field, you are dropping that capability.
Key facts
- ▸The four fields most often missing in real deployments are
caller.subject,decision.outcome,decision.ruleandrun.id. Without them you have traffic logs, not security events. - ▸
args.summarymust be a derived structure, never the raw argument object. Raw arguments routinely contain credentials, personal data and free text that you do not want in a long-retention index. - ▸The hash chain matters because the log is now evidence about an autonomous system’s behaviour, and the first question in any dispute is whether the record could have been edited.
| Field | Example | Required for |
|---|---|---|
ts, ts_decision | RFC 3339, millisecond precision | Ordering, and measuring decision latency separately from upstream latency |
caller.subject | alice@corp.example | Attribution to a human who can be asked what happened |
caller.assurance | aal2, step_up | Detecting privileged action under weak authentication |
agent.id, agent.version | support-triage@3.4.1 | Attributing a behaviour change to a deployment |
run.id | ULID per agent run | Reconstructing a whole episode from one alert |
session.id | ULID per client session | Correlating across runs by the same principal |
server.id | crm-prod | Blast-radius questions after a server compromise |
tool.name, tool.version | crm.contact.update@2 | Detections keyed on capability rather than server |
args.summary | {amount:1200,currency:GBP,id:sha256:9f2…} | Threshold and pattern detections without storing raw values |
args.classes | [pii.email, financial.amount] | Routing events to the right retention tier and the right analyst |
decision.outcome | allow / deny / approve / transform / route / shadow | Every meaningful detection on this page |
decision.rule | payments/refund-ceiling | Knowing which control fired, and tuning it |
decision.policy_version | git:9c41ab2 | Reconstructing what the rules were at the time |
approval.ref | approval record id, approver, timestamp | Non-repudiation for high-consequence actions |
latency.decision_ms, latency.upstream_ms | 7, 412 | Separating a slow policy layer from a slow upstream |
upstream.status | 200, 409, timeout | Distinguishing prevented from failed from succeeded |
data.sensitivity | restricted | Regulatory reporting and retention selection |
event.hash, event.prev_hash | hash chain over the record | Detecting later tampering with the log itself |
Two fields deserve special attention because they are what makes agent telemetry different from API telemetry: run.id and decision.rule. The first turns a single alert into a reconstructable episode. The second turns a denial into a tuning conversation instead of a mystery.
Normalising to ECS and OCSF at the edge
Normalise once, at emission, and never in the search bar. Teams that skip this end up with three generations of field names and detections that only one person can maintain. The mapping below is not exotic; agent decisions fit the existing vocabularies for authorisation events with very little strain.
- ›Every detection carries its own renaming logic
- ›Two schema generations coexist indefinitely
- ›Dashboards break when emission changes
- ›Cost of a field rename is N queries
- ›Detections read one stable field set
- ›Emission changes are absorbed in one place
- ›New SIEM is a collector config change
- ›Cost of a field rename is one config
| Canonical field | Elastic Common Schema | OCSF | Note |
|---|---|---|---|
caller.subject | user.name, user.email | actor.user.name | Human, not the service account |
agent.id | service.name + labels.agent | actor.process.name | ECS has no agent concept; label it explicitly |
tool.name | event.action | api.operation | Treat the tool as the action taken |
decision.outcome | event.outcome + labels.decision | status_id / action_id | ECS outcome is success/failure only, so carry the six-value decision alongside |
decision.rule | rule.name, rule.id | policy.name | Maps cleanly in both |
server.id | destination.address + service.target | dst_endpoint | Logical server id beats hostname |
run.id | trace.id | metadata.correlation_uid | Reuse the tracing identifier if you have one |
args.classes | labels.data_classes | data_classification | Drives retention routing |
event.hash | event.hash | metadata.event_code + custom | Keep the chain link even where the target schema has no home for it |
If you run an OpenTelemetry collector already, emit decisions as span events with the GenAI semantic-convention attributes plus the fields above, and let the collector fan out to the SIEM, the data lake and the long-retention store. One pipeline, three destinations, one schema.
Seven detections worth building first
These are ordered by value per hour of engineering, and each is stated with the false positive it will generate — because a detection shipped without its known false positive gets disabled within a fortnight.
Policy probing: denials followed by an equivalent success
Same run or session: two or more denials on a capability class, then an allowed call to a different tool achieving a similar effect. This is the signature of something searching for a path around policy, whether that something is a confused planner or an injected instruction.
False positive: legitimate fallback logic in well-written agents. Suppress by allowlisting known fallback pairs from your routebook, not by widening the time window.
Sensitive read followed by outbound-capable write
Within one run: a tool call classified as reading restricted or personal data, then a call to any tool capable of egress — email, webhook, file share, external API. The two-step exfiltration pattern that conventional DLP misses because both calls are authorised.
False positive: reporting and notification workflows that legitimately do exactly this. Requires a per-workflow allowlist; expect a week of tuning and do not skip it.
Volume anomaly against the agent’s own baseline
Calls per minute for a specific agent and tool exceeding its trailing baseline by a large factor. Agents fail loudly and repetitively; a retry loop against a payment tool is a financial incident, not a performance issue.
False positive: legitimate batch runs at period end. Baseline per agent per weekday, and exclude declared batch windows explicitly.
Privileged action at low authentication assurance
A tool in a high-risk class executed where caller.assurance is below the level policy requires, or where the caller identity is a shared service account rather than a person.
False positive: legitimate automation with no interactive human. Those callers need an explicit exception record with an owner and an expiry, which is a control improvement disguised as tuning.
Approval anomalies
Approvals granted in under five seconds, approvals by the requester’s own account, approvals of a materially different request than the one approved, or a spike in a single approver’s throughput.
False positive: genuinely trivial approvals that a competent approver can judge instantly. If most approvals are like that, the threshold is wrong and the control is theatre.
New tool, new server, or new argument shape
First observation of a tool name, server identifier or argument key for a given agent. Cheap to implement, disproportionately valuable, and the fastest way to notice an unreviewed server appearing in production.
False positive: every deployment. Route to a low-noise queue reviewed daily rather than to paging, and expect the volume to fall as the estate stabilises.
Log-integrity break
A gap in the hash chain, a sequence discontinuity, or a decision event whose policy version does not exist in the repository. Rare, and unambiguous when it fires.
False positive: collector restarts and buffered replays. Fix by making the chain per-emitter and reconciling on restart, not by relaxing the check.
Notice how many of these depend on run.id. Detections one, two and five are impossible without a correlation identifier linking calls in the same agent episode, which is why it appears in the schema despite looking like an observability field rather than a security one.
The ingest arithmetic, done before the pilot
SIEM licensing is usually priced on ingest volume, and agent telemetry has a very different shape from human telemetry: fewer principals, vastly more events each. The arithmetic is simple and almost nobody does it before the pilot, which is how a successful agent programme becomes an unbudgeted SIEM invoice.
Key facts
- ▸A single continuously running agent can exceed the daily event volume of a hundred employees. Budgeting on headcount is the standard mistake.
- ▸Denials, approvals and transforms are typically under 5% of total volume and carry nearly all the detection value. Retain them in full, forever, and sample the rest.
- ▸Two-tier retention is what makes seven-year evidence affordable: a queryable hot tier for operations, an immutable cold tier for audit.
| Tactic | Volume effect | What you lose |
|---|---|---|
| Summarise arguments, hash long values | 60–75% reduction | Ability to inspect exact payloads in the SIEM; keep those in a short-retention store instead |
| Sample allow decisions at 1 in 10 | up to 50% reduction | Precise volume baselines — compensate with pre-aggregated counters |
| Never sample deny/approve/transform/step-up | — | Nothing. This is the signal; sampling it is self-defeating |
| Two-tier retention: 90 days hot, 7 years cold | Large cost reduction | Instant search on old events; acceptable for evidence you retrieve rarely |
Drop health checks and tools/list polling | 10–30% reduction | Very little, provided you keep a daily aggregate |
| Pre-aggregate counters at the edge | Enables aggressive sampling | Per-event fidelity on high-volume allows |
Daily ingest estimate
agents × calls_per_agent_per_day × bytes_per_event = daily bytes 20 agents × 12,000 calls × 1.4 KB ≈ 336 MB/day ≈ 10 GB/month with full raw arguments (≈ 6 KB/event): ≈ 43 GB/month
Twenty agents is a modest pilot, and the difference between summarised and raw arguments is roughly four times the bill. This is the single highest-leverage decision in the integration.
Keep raw arguments somewhere — in a short-retention, access-controlled store with its own audit trail, referenced by hash from the SIEM event. Investigations occasionally need the exact payload; your seven-year compliance index does not.
Platform notes: Splunk, Sentinel, OpenTelemetry
The integration mechanics are unremarkable in every platform. What differs is where normalisation belongs and how retention tiering is expressed.
Splunk
Emit newline-delimited JSON to HTTP Event Collector with a dedicated sourcetype per event class. Do field mapping at emission, not in props.conf, so that searches stay portable. Use summary indexing for the per-agent baselines detection three needs, and route the cold tier to a frozen archive with a documented restore path.
Microsoft Sentinel
Send via Log Ingestion API into a custom table with a Data Collection Rule that performs the ECS-to-table mapping. Use auxiliary or basic logs for high-volume allow decisions and the analytics tier for decisions and approvals — that split is the whole cost story. Write analytics rules against the decision fields, not the raw payload.
Elastic
Emit ECS directly and you are largely done. Use data streams with an index lifecycle policy for the hot/cold split, and runtime fields for the handful of attributes you did not anticipate rather than reindexing.
OpenTelemetry collector
The best option if you already run one. Emit decisions as log records or span events carrying GenAI semantic-convention attributes plus the canonical fields, then fan out to SIEM, lake and archive. One emission path, three destinations, one schema to maintain.
Data lake or warehouse
Worth having alongside the SIEM for the analyses SIEM query languages handle poorly: cohort behaviour by agent version, policy drift over quarters, cost per outcome. Cheaper per gigabyte and better at joins.
What not to do
Do not point agents at the SIEM directly, and do not let each team invent its own event shape. Both produce an estate where the SOC receives six incompatible dialects of the same event and trusts none of them.
A four-week rollout that ends with working detections
The failure mode of SIEM integration projects is stopping after the pipe is connected, at the exact point where cost has been incurred and value has not. This sequence is arranged so that each week produces something a security team can use.
One agent, full fidelity, no detections
Emit the full 18-field event for a single agent with raw arguments retained in a short-retention store. Measure real bytes per event and real calls per day. Every later estimate depends on these two numbers being observed rather than assumed.
Normalisation and retention tiering
Map to ECS or OCSF at the edge, split hot and cold tiers, switch to summarised arguments, and confirm the volume reduction matches the projection. Fix the schema now, while exactly one producer exists.
Detections one, three and six
Build the three cheapest high-value detections — policy probing, volume anomaly, first-observation — and tune them against the two weeks of data you now hold. Ship them with their documented false positives and a named owner.
Estate-wide emission, then detections two, four, five, seven
Extend emission to every agent, then add the detections that need cross-agent context. Review deny rate and approval anomalies with the platform team, because most early alerts are governance defects rather than attacks — and fixing those is the point.
A useful acceptance test at the end of week four: pick a tool call from three weeks earlier and reconstruct, from the SIEM alone, who caused it, what policy said, who approved it, whether it succeeded, and what else happened in the same run. If any of those five is unanswerable, a field is missing.
Next step
Emit the decision, not just the request
Barzel Central Gateway produces a decision record per tool call with outcome, rule and policy version already populated, in a shape that maps to ECS or OCSF without rework. That is the field set the seven detections above depend on.
What SIEM integration does not give you
A SIEM tells you what happened. It does not prevent anything, and the gap between those two facts is where most agent risk lives.
Three limits worth being explicit about.
- 01Detection is post-hoc by construction. A payment your SOC notices four minutes later has already left. Pre-execution enforcement and detection are complements, not alternatives — and the enforcement layer is the one that changes outcomes.
- 02Correlation depends on emission. If one agent in a chain does not carry the run identifier forward, the chain breaks precisely where multi-agent risk concentrates.
- 03Volume can bury signal. An integration that ships raw arguments for every allow decision produces an index nobody queries and an invoice everybody notices. Summarise deliberately.
Frequently asked questions
What is MCP SIEM integration?
MCP SIEM integration means emitting one structured event per Model Context Protocol tool-call decision — caller, agent, tool, argument summary, policy outcome, rule matched, correlation identifiers — normalising it to your SIEM’s schema, routing it through your existing collector, and pairing it with detections written specifically for agent behaviour.
What fields should an MCP audit event contain for a SIEM?
Eighteen: event and decision timestamps, human caller subject, authentication assurance, agent id and version, run id, session id, server id, tool name and version, argument summary, argument data classes, decision outcome, rule matched, policy version, approval reference, decision and upstream latency, upstream status, data sensitivity, and an event hash chained to the previous record.
How do I integrate MCP with Splunk?
Emit newline-delimited JSON to HTTP Event Collector using a dedicated sourcetype per event class, with field mapping done at emission rather than in props.conf. Use summary indexing to maintain per-agent baselines for volume-anomaly detection, and route the long-retention tier to a frozen archive with a documented restore path.
How do I integrate MCP with Microsoft Sentinel?
Send events through the Log Ingestion API into a custom table, using a Data Collection Rule to perform schema mapping. Put high-volume allow decisions in auxiliary or basic logs and keep denials, approvals and transforms in the analytics tier — that split is what makes the cost sustainable. Write analytics rules against decision fields rather than raw payloads.
Should MCP telemetry use ECS or OCSF?
Use whichever your SIEM already speaks: ECS for Elastic, OCSF where your vendor has adopted it, native tables for Sentinel. The important discipline is mapping at the edge, once, so that detections read one stable field set and a future platform change is a collector configuration rather than a rewrite of every query.
Can I use OpenTelemetry for MCP security telemetry?
Yes, and it is the best option if you already run a collector. Emit decisions as log records or span events carrying GenAI semantic-convention attributes plus the canonical decision fields, then fan out from the collector to the SIEM, a data lake and a long-retention archive. One emission path, several destinations, one schema.
How much SIEM volume will agent telemetry add?
Budget on decisions rather than headcount. Twenty agents making twelve thousand calls a day at 1.4 KB per summarised event is roughly ten gigabytes a month; the same estate shipping raw arguments is closer to forty-three. A single busy agent can exceed the daily event volume of a hundred employees.
Should I sample MCP events?
Sample routine allow decisions if volume demands it, and compensate with pre-aggregated counters at the edge. Never sample denials, approvals, transforms or step-up requirements: they are typically under five percent of volume and carry nearly all the detection value.
Will my existing UEBA rules detect agent misuse?
No. Human behavioural baselines assume working hours, session rhythm and human-scale request rates, all of which agents violate continuously. Human-tuned analytics therefore either stay silent on agent misuse or alert on everything. Agents need their own baselines, computed per agent and per version.
What is the highest-value agent detection to build first?
Repeated policy denials in one run followed by a successful call to a different tool that achieves a similar effect. That pattern indicates something searching for a path around policy — a confused planner, or an injected instruction steering the agent — and it is cheap to implement once decisions carry outcome and run identifiers.
How long should MCP audit events be retained?
Two tiers. Keep ninety days hot for investigation and tuning, and retain decisions on high-consequence actions — money movement, personal data, destructive operations — for as long as the relevant regulation or contract requires, commonly seven years, in an immutable cold store.
Is SIEM integration enough to satisfy an auditor?
It provides the activity record, but auditors typically also ask who authorised the control, what the policy was at the time, and whether the log could have been altered. Pair the SIEM feed with a version-controlled policy repository and a tamper-evident chain over decision records.
Glossary
- MCP decision event
- One structured record describing a single policy evaluation of a tool call: who, which agent, which tool, what outcome, which rule, and under which policy version.
- ECS (Elastic Common Schema)
- A field-naming specification for event data, widely used as a normalisation target so that detections read consistent field names.
- OCSF
- Open Cybersecurity Schema Framework: a vendor-neutral event schema increasingly adopted as a normalisation target across security platforms.
- Run identifier
- A correlation id shared by every tool call in a single agent episode, allowing an alert to be expanded into the full sequence that produced it.
- Argument summary
- A derived, classified representation of a tool call’s arguments — thresholds and hashes rather than raw values — safe to retain long term.
- Retention tiering
- Splitting telemetry into a short-lived queryable tier and a long-lived immutable tier, so evidence obligations do not price out operational search.
- First-observation detection
- An alert on the first time a given agent uses a tool, server or argument key, which surfaces unreviewed capability appearing in production.
- Hash chain
- Each record carrying a hash of the previous one, so that deletion or modification of history is detectable.
- Auxiliary or basic log tier
- A lower-cost, lower-capability ingest tier for high-volume events that do not need full analytics treatment.
- Policy probing
- A behaviour pattern in which denied attempts are followed by functionally equivalent attempts through different tools.
Standards and entities referenced
Every named framework on this page resolves to a public definition. If you are checking our claims, start here rather than with us.
Sources and further reading
Primary specifications and standards this article relies on. Where a claim is our own operating judgement rather than something a standard states, the text says so.
- 01 · OpenTelemetryOpenTelemetry — GenAI semantic conventions ↗Emerging standard attribute names for model and tool-call telemetry.
- 02 · NISTNIST SP 800-92 — Log Management ↗Baseline expectations for log content, retention and integrity.
- 03 · NISTNIST SP 800-53 Rev. 5 ↗Access control and audit control families that MCP-layer controls have to satisfy.
- 04 · MCP projectModel Context Protocol — specification ↗Normative source for tool schemas, capability negotiation and the authorization model.
- 05 · OWASP GenAI Security ProjectOWASP Agentic AI — Threats and Mitigations ↗Threat taxonomy specific to tool-using agents rather than to chat completions.
- 06 · NISTNIST SP 800-61 Rev. 3 — Incident Response Recommendations ↗The incident lifecycle agent-specific containment has to map onto.
- 07 · OWASP GenAI Security ProjectOWASP GenAI LLM Top 10 (2026) ↗Consensus risk list; excessive agency and prompt injection are the entries governance exists to bound.
- 08 · WikipediaMerkle tree ↗The structure behind append-only logs whose history cannot be silently rewritten.
- 09 · ISOISO/IEC 27001 — Information security management ↗The ISMS baseline that agent-layer controls have to fit inside rather than beside.
- 10 · IETFRFC 9457 — Problem Details for HTTP APIs ↗A machine-readable shape for the denial reasons a policy layer returns.
Last reviewed 2 September 2026 by Mark Alex. External links open in a new tab; we do not control their content.
Cite this article
Alex, M. (2026). MCP SIEM Integration: Getting Agent Activity Into Security Operations. Real Biz Digital. https://realbizdigital.net/insights/mcp-siem-integration/
Try the mechanics on a live server
To watch a real tools/list response, and see how much surface one server exposes, before you point a client at anything that governs production — Barzel Scripture Intelligence is free and public at scripture-intelligence-server.mcpize.run: no signup, no key, 54 tools. Setup is in the reference.
Buy it on the marketplace
Barzel Central Gateway is this layer, sold as a running product
Twenty-five tools covering identity-aware policy, tool routing, risk scoring, approvals, routebooks, workflow simulation and SIEM evidence. Ten policy inputs, six enforcement outcomes, per-user OAuth/OIDC. The Community tier is free, so an evaluation costs an afternoon rather than a purchase order.
| Plan | Price | Included | Right for |
|---|---|---|---|
| Community | Free | 1,000 tool calls/mo · full policy engine, registry, routing, audit | Evaluating the estate, or one team proving the path works |
| Starter | $10/mo | 10,000 calls/mo · everything in Community | One or two production agents against a handful of servers |
| Team | $79/mo | 100,000 calls/mo · routebooks, simulation, change impact | A platform team governing an estate of 5–20 servers |
| Business | $149/mo | 250,000 calls/mo · estate-wide evidence export | Multi-team governance with SIEM obligations |
Sold on the MCPize marketplace · prices as listed 2 Sep 2026 · the listing is authoritative
The five Barzel servers, and which problem each one is sold for
One estate rarely needs all five. This is the honest mapping, so you buy the layer your problem actually lives in.
| Server | Sold for | Entry price | Where it sits |
|---|---|---|---|
| Barzel Central Gateway | Knowing and governing the estate: inventory, registry, routing, risk scoring, approvals, evidence | Free, then $10–$149/mo | Control plane — decides what may be reached, and by whom |
| BarzelVault | Stopping a specific dangerous action before it executes, with proof afterwards | $199–$3,999/mo | Decision point — evaluates the individual call before execution |
| BarzelOps | Running real business workflows across HubSpot, Xero, Gmail, Drive and Slack under approval | Free, then $19–$199/mo | Execution layer — does the work the policy allowed |
| Barzel FinOps Atlas | Attributing AI spend to agents, tools and outcomes, then forecasting and capping it | Free, then $29–$799/mo | Economics layer — what the estate costs per outcome |
| Barzel Scripture Intelligence | A free, credential-free public MCP server to test clients and inspect real protocol traffic | Free, unmetered, no signup | Reference implementation — safe place to learn the protocol |
Written by
Mark Alex
Founder of Real Biz Digital and architect of the Barzel ecosystem — five MCP servers published and callable in public. Software developer, technology entrepreneur and mechatronics engineer, working across AI agent governance, MCP security, AI infrastructure, FinOps and intelligent operations.