Every AI Agent Under One Command Center: The Sentinel Framework for MuleSoft Agent Fabric

Every AI Agent Under One Command Center

A Forward Deployment Engineering playbook for MuleSoft Agent Fabric, Omni Gateway, and the agents you don't know you're running

Start with the question nobody in your company can answer

Walk into your next architecture review and ask one question:

How many AI agents and MCP servers are running against production systems right now, who owns them, and what can each one delete?

You will get three answers. The CIO will name the two funded programs. The platform team will name six more. And somewhere in a Slack channel you are not in, a senior engineer has a local MCP server wired to a production replica because it made his Tuesday faster.

All three answers are wrong, and the third one is the one that ends up in the incident review.

This is not a hypothetical. It is the exact shape of the shadow IT problem from 2013 and the shadow cloud problem from 2018, except this time the unmanaged asset does not just read data. It acts. It issues refunds, updates pricing, writes to the CRM, emails customers, and calls another agent that calls another agent that calls SAP.

The API sprawl decade taught enterprises to put a gateway in front of everything. The agent decade is going to teach the same lesson at roughly ten times the cost, because an unmanaged API is a data leak and an unmanaged agent is an unsupervised employee with your service credentials and no memory of what it did yesterday.

This post is the short version of the framework my team uses to fix it. We call it Sentinel.

First, an honest disclaimer, because the market is full of vapour

Sentinel is not a MuleSoft product. It is not a Salesforce product. It is not software you can buy.

Sentinel is Keneland's delivery framework — a set of reference architectures, scoring models, entitlement templates, Omni Gateway policy bundles, and Command Center dashboards that we assemble on top of the MuleSoft Agent Fabric primitives that Salesforce actually ships today.

I am being blunt about this because there is a lot of AI-governance marketing right now that describes capabilities nobody has built. If a partner shows you a slide with a product name you cannot find in docs.mulesoft.com, ask them which SKU it is. Then watch what happens.

Here is the honest split.

What MuleSoft ships today (as of this writing)

CapabilityProduct primitiveStatusCentral catalogue of agents, MCP servers, model proxies, APIs, gatewaysAgent Registry / Portfolio in Anypoint ExchangeGAAutomatic discovery of agents on Amazon Bedrock, Google Vertex AI, Microsoft Copilot StudioAgent ScannersGARuntime policy enforcement across APIs, agents, MCP, and LLM trafficOmni Gateway (Flex Gateway for MCP & A2A)GAIntelligent routing of tasks across agent domainsAgent BrokerGAVisual map of the agent network, call volume, and which agents lack policy coverageAgent VisualizerGAAgent acting under a specific user's identity, with authorizationTrusted Agent IdentityGAMetrics, logs, traces for agentic assetsAnypoint MonitoringGA

That is a genuinely strong foundation. Salesforce got the primitives right, and Agent Visualizer flagging agents with no Omni Gateway policy coverage is one of the most quietly useful features in the stack.

What you still have to build yourself

GapWhy it mattersA risk score per agentThe Registry tells you an agent exists. It does not tell you the refund agent is the most dangerous object in your estate.A blast-radius query"If this MCP server is compromised, what is reachable?" is a graph traversal nobody has written for you.Entitlement policy as codeOmni Gateway enforces policy. It does not author your allow/deny model, your transaction ceilings, or your human-approval thresholds.Cost attribution to a business processToken spend by agent is not the same as cost per closed quote. The second one is the number your CFO will ask for.Behavioural baselines and anomaly detectionNothing out of the box knows that 74,000 customer record reads in eight minutes is abnormal for this specific agent.A rehearsed kill switchEvery platform has the controls. Almost nobody has run the drill.One screen an executive will actually look atRegistry, Visualizer, and Monitoring are three consoles for three personas. Your CISO wants one.

Sentinel is the second table. That is the entire proposition. We do not rebuild what MuleSoft already gave you — we make it posture-aware.

The five control loops

Sentinel runs as five loops, in this order. The order is not decorative. Skipping straight to governance is the single most common failure I see, and it is why so many "AI governance programs" govern the twelve agents IT knew about and none of the forty that mattered.

DISCOVER  →  GRAPH  →  SCORE  →  GOVERN  →  WATCH
    ↑                                          │
    └──────────────────────────────────────────┘

Loop 1 — Discover: find the agents that were never on a slide

Agent Scanners handle the well-lit rooms: Bedrock, Vertex AI, Copilot Studio, and assets registered in Exchange. Run them first. That is a one-week win and it will already surprise your architecture team.

The uncomfortable part is everything else:

Local MCP servers on developer laptops, talking to prod replicas over a VPN
MCP servers embedded in SaaS products your business units bought on a corporate card
Python and Node agents running on someone's EC2 instance under a personal IAM role
LangGraph and CrewAI prototypes that quietly became load-bearing
Agentforce agents built by an ops team with permission set access nobody reviewed

How we actually find these — and the honest limits. We work four evidence sources: cloud control-plane inventory, Kubernetes workload and service metadata, egress telemetry to known LLM and model endpoints from your existing proxy and DNS logs, and source-control scanning for MCP configuration files and agent framework imports.

Note what is not on that list: we do not install packet sniffers across your VPCs, and we cannot see an agent running fully air-gapped on a laptop that never touches a corporate network path. Anyone telling you they have 100% discovery coverage is selling you something. Realistic target for a first pass on a mid-market estate is 85–90% of agents that touch a corporate network or cloud account, and we tell you explicitly which surfaces we could not see.

Every discovered asset lands in the existing Agent Registry, not a Keneland-owned side catalogue. This matters. The moment a partner stands up a parallel inventory outside Anypoint, you own two sources of truth and you will spend the next two years reconciling them.

Discovery output, per asset: external ID, asset type, endpoint, protocols, owner (or UNKNOWN, which is itself a finding), authentication method, data classifications touched, evidence trail, and a confidence score.

Loop 2 — Graph: turn a list into a dependency model

A flat inventory answers "what exists." It cannot answer the questions that actually get asked in an incident.

The Asset Graph models relationships — CALLS, USES_TOOL, USES_MODEL, READS, WRITES, ACTS_ON_BEHALF_OF, DELEGATES_TO, GOVERNED_BY — on top of Registry identities. Agent Visualizer gives you the picture; the graph gives you the query.

Sales Copilot Agent
   ├── Claude Sonnet (external model)
   ├── Salesforce MCP
   │      ├── Account API
   │      ├── Opportunity API
   │      └── Customer PII  ⚠
   ├── Slack MCP
   └── Pricing Agent
          ├── Gemini (external model)
          └── SAP Pricing API  ⚠ write

Six questions we make the graph answer on day one:

Which agents can reach customer PII, directly or through two hops?
Which agents can move money or change price?
Which MCP servers are reachable from an agent that is itself reachable from outside the tenant?
Which agents authenticate with a shared service credential rather than a delegated user identity?
Which agents span two segregation-of-duties boundaries — HR and Finance, or Deal Desk and Approvals?
If asset X is compromised, how many assets, sensitive data resources, and write-capable tools are inside the blast radius?

Question 6 is the one that changes budget conversations. A number like "this one unowned MCP server puts 41 assets, 4 sensitive data stores, and 7 write-capable tools in reach" does more in a steering committee than any maturity model.

Loop 3 — Score: make risk explainable, not vibes-based

Every asset gets a score from 0–100, built from weighted, evidenced factors. The score is worthless unless it explains itself, so every score ships with its arithmetic.

Customer Refund Agent            RISK 87 — CRITICAL

+20  Can initiate financial transactions (issue_refund)
+15  Reads customer PII
+20  Sends context to an unapproved external model
+10  MCP server exposes no OAuth
+10  Authenticates with a shared service credential
+10  No human-approval gate at any transaction value
+07  Unrestricted tool access on the connected MCP server
-05  Partial Omni Gateway coverage

In plain English: this agent can look up a customer and refund
their money, using a credential shared with four other services,
with no human in the loop and no transaction ceiling.

Severity bands: 0–24 LOW · 25–49 MODERATE · 50–74 HIGH · 75–100 CRITICAL.

Two rules we enforce on scoring, both learned the hard way:

Weights are configuration, not code. A hospital and a fintech do not weight PII and financial authority identically. If your scoring model cannot be re-profiled without a release, it will be ignored within a quarter.
Every factor carries a remediation. A score with no "do this next" is a dashboard decoration. Each factor maps to a specific control: apply OAuth, replace shared credential with delegated identity, set transaction ceiling, route through gateway.

Loop 4 — Govern: entitlements as code, enforced at the gateway

This is where Sentinel stops being analysis and starts being control. The pattern is deliberately boring, because boring is what survives an audit: the entitlement document is the intent, Omni Gateway is the enforcement, and the two are never allowed to drift.

yaml

yaml
apiVersion: agentfabric.keneland.io/v1
kind: AgentEntitlement
metadata:
  name: sales-copilot-default
spec:
  subject:
    agentId: sales-copilot

  allow:
    agents:    [pricing-agent, customer-agent]
    mcpServers:[salesforce-mcp]
    tools:     [get_account, get_opportunity, create_quote]
    models:    [claude-sonnet, gpt-enterprise]

  deny:
    tools:     [delete_account, issue_refund, export_customers]

  constraints:
    transaction:
      currency: USD
      maximum: 5000
    humanApproval:
      requiredWhen:
        transactionAmountGreaterThan: 1000
    dataClassifications:
      allowed: [INTERNAL, CUSTOMER_CONFIDENTIAL]
      denied:  [PCI_SECRET]

Evaluation semantics, in order: explicit deny beats allow → subject identity must be verified → delegated user context evaluated → tool and resource scope evaluated → data classification checked → transaction conditions checked → human approval may return CONDITIONAL → default is DENY.

That last line is the one to argue about internally before you build anything. Default-deny for agents is operationally painful in month one and non-negotiable by month six. Enterprises that start default-allow "just until we finish the rollout" never finish the rollout.

The corresponding gateway policy set we deploy: agent identity verification, entitlement enforcement, MCP tool authorization, A2A peer authorization, delegation context validation, model allow/deny, data classification guard, transaction limit, human approval gate, token budget, prompt and response inspection, agent rate limit, loop guard, and emergency quarantine.

Latency budget matters here. Inline enforcement has to be deterministic and cheap — we target p95 ≤ 20 ms service-side for a cached entitlement decision. Anything expensive (graph traversal, behavioural analytics, trust evaluation) runs asynchronously unless a specific high-risk workflow explicitly opts into inline evaluation. If your governance layer adds 400 ms to every agent hop, engineering will route around it, and they will be right to.

The A2A firewall

Agent-to-agent traffic is the part most programs forget, and it is where lateral movement lives.

Sales Agent
   ├── ALLOW        → Pricing Agent
   ├── ALLOW        → CRM Agent
   ├── CONDITIONAL  → Legal Agent   (human approval)
   └── BLOCK        → Payroll Agent

The operating principle: never trust an agent just because it is inside the tenant. Micro-segmentation for agents is the same idea as micro-segmentation for workloads, and it earns its keep the first time a prompt-injected agent tries to hop somewhere it has no business being.

Loop 5 — Watch: runtime behaviour, cost, and the kill switch

Posture is a snapshot. Agents are non-deterministic, so the snapshot is stale the moment you take it.

Deterministic detections (cheap, inline, no ML): a denied tool was invoked, an unapproved model destination appeared, agent identity was missing, PII went to a prohibited endpoint, a transaction exceeded its ceiling, a quarantined asset was called.

Behavioural detections (baselined per agent, per version, evaluated asynchronously): mass data retrieval, token spikes, tool-invocation deviation, A2A fan-out anomalies, repeated authorization failures, recursive loops, abnormal model switching, denial-of-wallet patterns.

ALERT — POSSIBLE DATA EXFILTRATION

Agent:        MarketingResearchAgent
Baseline:     50–100 customer records/day
Observed:     74,231 records / 8 minutes
Destination:  External LLM endpoint
Confidence:   0.98
Action:       QUARANTINE (pending approval)

Agent FinOps runs on the same telemetry: tokens per task, cost per task, cost per successful task, tool calls per task, agent hops per task, duplicate call rate, retry rate, context growth rate, model escalation rate. The metric that lands with a CFO is not "we spent $416k on tokens." It is "we spent $18 per successfully generated renewal quote, and $11 of that is a single MCP tool returning a 220 KB payload that gets re-injected into context on every turn."

That second sentence is a fixable engineering problem. The first is a line item nobody can act on.

The kill switch. Supported actions: quarantine agent, disable agent, disable MCP server, disable a single MCP tool, revoke identity, revoke token, block model, block A2A route, terminate active task, disable an entire agent network.

Every action authenticated, authorized, idempotent, immutably audited, and explicitly reversible. And — this is the part that gets skipped — rehearsed. We run a quarantine drill in a lower environment during the engagement and we time it. If your team cannot pull a rogue agent out of production in under five minutes with an audit trail intact, you do not have a kill switch. You have a button nobody has ever pressed.

The Command Center

Registry, Visualizer, and Monitoring are excellent tools for three different people. The CISO, the CFO, and the VP of Platform each want one screen, and none of them want yours.

The Command Center is an aggregation layer — not a source of truth — composing Registry inventory, graph data, risk posture, monitoring metrics, threat findings, cost analytics, and enforcement state.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
             AGENT COMMAND CENTER
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ESTATE          Agents 34 · MCP Servers 19 · Models 6
                Tools 218 · Agent Networks 4

POSTURE         Shadow agents          7
                Unmanaged MCP servers  5
                Critical findings      3
                PII access            12
                Write access           9
                Financial access       2

SPEND           Month to date   $14,300
                Forecast        $21,000
                Identified waste $4,100

ACTIVE          🔴 CustomerDataAgent — mass PII retrieval
                🔴 Payroll MCP — authentication disabled
                🟠 SalesAgent — token consumption +340%
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Numbers above are illustrative and sized to a real mid-market estate — roughly 30–40 agents, not 2,000. If a vendor shows you a governance dashboard with 1,847 agents on it, ask whether that is their customer's number or their designer's.

What Sentinel deliberately does not promise

This section exists because it is the fastest way to tell the difference between a partner who has shipped this and one who has read about it.

We do not claim to detect hallucinations. What we do is narrower and actually verifiable: compare an agent's claim against authoritative system state. If the agent says "I refunded the customer $1,500" and the refund API returned FAILED, that is a detectable action/response inconsistency and we block the response. That covers a meaningful slice of the damage. It is not hallucination detection, and calling it that is dishonest.

We do not put a dollar figure on "AI slop" in week one. Efficiency scoring needs a baseline, and a baseline needs weeks of clean telemetry from a stable agent version. Anyone quoting you an annualised waste number before they have instrumented your traffic is generating it in a spreadsheet, not a system.

We do not promise discovery of agents outside your network perimeter. See Loop 1.

We do not build a parallel control plane. Everything lands in Anypoint. If you fire us, you keep a working, supportable estate — not a Keneland-shaped hole in your architecture.

The engagement model

We deliver this the way we deliver everything: Forward Deployment Engineering. A small embedded senior team sits inside your platform and security org, personally owns the hardest 20%, and hands over the rest as reusable patterns. Daily working sessions, not weekly steering committees.

Phase 0 — Agent Posture Assessment (4 weeks, fixed fee)

WeekWorkExit gate1Agent Scanners enabled across cloud accounts; Registry baseline; stakeholder interviewsEvery known agent registered2Shadow discovery across egress telemetry, K8s metadata, source controlUnknown-asset list published with evidence and confidence3Asset graph built; blast-radius queries; risk scoring applied and calibrated to your weightsRanked risk register, top 10 assets with named remediations4Entitlement design for the top 3 agents; gateway policy mapping; findings readoutBoard-ready posture report + prioritised 90-day plan

Deliverables: complete AI asset inventory with ownership assigned, dependency graph, scored risk register, entitlement drafts, Omni Gateway policy mapping, and a remediation roadmap with effort estimates.

The one gate that matters: at the end of week 4, an executive can name every agent in the estate, its owner, and its blast radius. If they cannot, we did not finish.

Phase 1 — Govern (weeks 5–12)

Entitlement engine live, Omni Gateway policies enforcing on the top-risk agents, MCP tool authorization, model allow/deny, A2A authorization, quarantine state operational, Command Center inventory and risk views shipped. Exit criterion: Discover → Register → Graph → Score → Recommend → Govern runs end-to-end on your tenant, on Agent Fabric primitives, without a human in the middle.

Phase 2 — Watch (weeks 13–24)

Behavioural baselines, threat analytics, exfiltration signals, loop detection, cost attribution, efficiency scoring, response trust checks on high-risk workflows, approval-based remediation, expanded kill switch, threat and FinOps views. Exit criterion: Sentinel detects a high-confidence runtime anomaly, correlates it to graph and risk context, and executes an authorised remediation through existing Agent Fabric enforcement — and we prove it in a live drill.

Sizing this honestly

If you are running three agents in a pilot, you do not need this. Register them, put Omni Gateway in front of them, and get on with your life. Come back when you hit fifteen.

The inflection point is roughly where any of these become true:

More than 10–15 agents or MCP servers in or near production
Any agent with write access to a system of record
Any agent that can move money, change price, or touch PHI/PCI
More than one team building agents independently
An auditor, regulator, or enterprise customer has started asking about AI controls
Monthly LLM spend past ~$10k with no attribution model
You have already had one "wait, who built that?" moment

Two or more of those, and the cost of not having a control plane is already higher than the cost of building one. You just have not received the invoice yet.

Who this is for

CISOs and security architects who have been handed AI risk with no inventory to work from
Platform and integration leaders running MuleSoft who need to extend Agent Fabric past discovery into posture
RevOps and Service leaders deploying Agentforce at scale who need entitlement boundaries before, not after, the first bad refund
CFOs and FinOps teams who can see the LLM bill but not the unit economics behind it
Salesforce practice leads at SI partners who want a defensible governance accelerator rather than another slideware framework

The strategic point, in one line

The API decade made the gateway the control point between applications and enterprise action. The agent decade makes the fabric the control point between AI reasoning and enterprise action.

MuleSoft built the primitives. Sentinel is how you turn them into posture — discovered, identified, catalogued, authorised, governed, observed, protected, and optimised — before your first agent incident writes the policy for you.

Start with the inventory

→ Book a 45-minute Agent Posture Review. Bring your platform lead and whoever owns security. We will walk your current agent estate, identify the three highest-probability shadow surfaces, and tell you honestly whether you need a 4-week assessment or just a weekend of gateway configuration.

No deck, no drip sequence. If the answer is "you're fine, register your agents and call us in six months," that is what you will hear.

Schedule a consultation → Free Salesforce Health Assessment → AI Consulting services →

About the author

Mani G is an Applied AI Strategist focused on GTM technology. He has spent the last decade designing agentic AI systems, multi-tenant SaaS platforms, and Salesforce-native revenue automation for enterprise customers. Recent work includes NOVA, a LangGraph-based agentic GTM orchestrator with native Salesforce MCP integration, and ASDA, a multi-agent engineering team orchestration platform.

If you want to talk about agent governance, Agentforce rollout, or AI posture management for BFSI, reach out at Mani@keneland.com.

Sources & further reading

MuleSoft Agent Fabric overview — https://www.mulesoft.com/ai/agent-fabric
Agent Fabric documentation — https://docs.mulesoft.com/general/agent-fabric-overview
Agent Visualizer documentation — https://docs.mulesoft.com/agent-visualizer/
Agent Fabric release notes — https://docs.mulesoft.com/release-notes/agent-fabric/agent-fabric-release-notes
Salesforce Agent Fabric announcement — https://www.salesforce.com/news/stories/mulesoft-agent-fabric-announcement/

Tags: MuleSoft, Agent Fabric, Agentforce, MCP, A2A, AI Governance, Shadow AI, Omni Gateway, Agent FinOps, Forward Deployment Engineering

All Articles