Solutions
Zero-trust architecture for tools, resources, and secrets
deny
by default
Unlisted tools and servers are invisible to the client.
0
long-lived secrets in agents
JIT injection and rotation at the gateway.
arg
level authorization
Policies can constrain project, account, and path.
100%
calls audited
Discovery and invocation share one evidence store.
Enterprise architecture
Zero-trust MCP security path
Every tool discovery and invocation is authenticated, authorized, vault-injected, inspected, and audited—default deny.
Zero-trust MCP security path
ForgeCruxProbing Deeper, Stacking PrecisionMCP clients
IDE, agents, apps
Identity
OIDC, mTLS, SCIM
MCP Gateway
Virtual catalog · arg-level RBAC · DLP · vault JIT · HITL · sandbox egress
Tool backends
SaaS, data, internal
SIEM / WORM
100% call audit
Default deny
Unlisted tools invisible
Secrets never in agents
Vault lease per call
Mutating tools
HITL until evals pass
Tools are production APIs
The same discipline you apply to northbound APIs applies to every agent tool call.
Secrets stay in the vault
Models and agents never hold raw database, SaaS, or cloud keys.
Forensics in minutes
Security can answer who invoked which tool, with which args, under which policy version.
Key Capabilities
Complete MCP Security capabilities
Everything required to publish, secure, mediate, observe, and operate mcp security workloads on ForgeCrux.
Enterprise uses
Who needs zero-trust MCP and what they block.
- Security: default-deny tools, DLP on args/results, SIEM evidence
- Platform: one virtual catalog per team instead of sprawl of stdio servers
- Developers: IDE MCP clients that never hold SaaS or DB keys
- Agent operations: mutating production tools behind HITL
- GRC: recertify who can call which tool under which policy version
- SRE: rate limits, circuit breakers, and session revoke on abuse
Installation & deployment
Put the gateway in front of every MCP server.
- MCP Gateway data plane in SaaS, VPC, Kubernetes, or air-gapped
- Vault / KMS for JIT credential injection
- OIDC, mTLS, and SCIM for clients and operators
- Network egress allow lists and DNS policy at the sandbox
- Environment isolation so dev catalogs cannot reach prod servers
- WORM audit store and SIEM correlation IDs
Setup & onboarding
Inventory, vault, virtualize, then enforce.
- List stdio and remote MCP servers used by IDEs and agents
- Move secrets out of configs into the ForgeCrux vault
- Publish virtual catalogs—one endpoint per team
- Point clients at the gateway; block direct server URLs
- Enable arg-level policies and DLP on tools/call
- HITL on mutating prod tools until red-team evals pass
Security & forensics
Authenticate, authorize, inject, inspect, audit.
- Default deny; unlisted tools are invisible
- Tool- and argument-level RBAC/ABAC
- Zero long-lived secrets in agents
- Prompt-injection defenses on tool descriptions and results
- Sequence anomaly detection and automatic agent pause
- 100% audit of list, read, subscribe, and call
Prevent
Stop unauthorized and unsafe tool use before it happens.
- Default-deny catalogs and tool aliases
- Parameter constraints and schema validation
- Network egress and DNS allow lists
- Prompt-injection defenses on tool descriptions and results
- Environment isolation (dev tools cannot hit prod)
- Device and workload posture checks
Detect and respond
See abuse quickly and contain it.
- Sequence anomalies (recon then exfil patterns)
- Volume and off-hours detections
- Automatic session revoke and agent pause
- SOAR webhooks and SIEM correlation IDs
- Forensic export of call payloads under legal hold
- Tabletop and red-team MCP scenarios
Data flows
How requests, policies, and telemetry move through ForgeCrux in this solution.
Authorized tool invocation
Standard call with vaulted credentials.
tools/call
JSON-RPC
AuthN/Z
Token + policy
Inject secret
Vault lease
Backend
Scoped action
Redact + log
Result to client
Blocked or approved path
When policy denies or requires a human.
Sensitive tool
e.g. prod write
PDP deny/queue
Risk tier
HITL
Owner decision
Execute or reject
Ticketed
Audit
Who approved
How teams run MCP Security on ForgeCrux
Inventory MCP servers
List stdio and remote servers in use by IDEs and agents.
Move secrets
Strip keys from configs; register them in the ForgeCrux vault.
Publish virtual catalogs
One endpoint per team with only their tools.
Enforce in path
Point clients at the gateway; block direct server URLs.
Turn on HITL
Mutating production tools require approval until evals pass.
Prove it
Feed audit to SIEM and run an access recertification.
Related Products
MCP Gateway
ForgeCrux MCP Gateway is the governed fabric for Model Context Protocol: server registry, tool discovery, OAuth, RBAC, credentials, virtual servers, traffic control, and full audit of every tool call.
AI Governance
ForgeCrux AI Governance is the control layer between applications, agents, and models: identity, data classification, guardrails, residency, spend, evaluation, and immutable audit—enforced in the data path, not in a slide deck.
Agent Gateway
ForgeCrux Agent Gateway gives every agent an identity, permissions, routing, memory controls, guardrails, tracing, evaluation, cost limits, and lifecycle—so multi-agent systems can reach models, APIs, MCP tools, and data without unmanaged autonomy.
Ready to get started with MCP Security?
Talk to our team about deploying MCP Security in your enterprise environment.