Build the connector once.
Use it everywhere.
Create system connectors without code. Every action automatically becomes a governed workflow step, a policy-scoped MCP tool for agents, and a runtime-authorized operation — with the same proof chain everywhere.
One definition. Three surfaces. One policy model. One proof chain.
Every integration team rebuilds the same action three times
Once for the system connector. Again for the workflow step. Again for the agent tool surface. That creates drift, duplicate work, and inconsistent governance. When the API changes, you fix it in three places — or you don't, and the audit finding writes itself.
Connector ≠ workflow step ≠ agent tool
In most platforms, the connector, the workflow action, and the agent tool are three separate implementations. Three schemas, three authorization models, three places things can break.
Custom code for every integration
Connecting a new system means writing adapter code, mapping fields, handling auth flows, and maintaining it forever. Your integration backlog keeps growing.
Agents get tools with no governance layer
Exposing a connector to an AI agent usually means wrapping it in a separate MCP tool definition with its own schema. Authorization, credential isolation, and proof are afterthoughts — if they exist at all.
No proof that connectors and tools match
When the auditor asks "does the tool the agent called match what the connector actually executes?" — you don't have an answer. The tool definition and the connector are managed separately.
One connector definition creates three governed surfaces
Define a system connector once — in the visual editor or YAML. Every command and action in that connector automatically becomes all three: a system action, a workflow step, and a governed MCP tool. Same schema. Same authorization. Same proof chain.
System action
A governed operation you can call directly against the target system — database, SSH, LDAP, Azure, SAP, SCIM, ServiceNow, Jira, and 60+ more. Every call authorized by the OpenID AuthZEN PDP and receipted.
Workflow step
The same action appears as a draggable node in the visual workflow designer. 60+ components for graph-based orchestration. Per-action authorization at every step. No re-implementation.
Governed MCP tool
The same action is published as a policy-scoped MCP tool that any authorized agent can discover and invoke. CDA x-fields make it self-describing for AI. Credential isolation ensures the agent never sees tokens.
System editor or YAML
commands + schemas
MCP tool defs + workflow
nodes + AI context
AuthZEN policy bindings
per action, per surface
Humans, workflows,
and agents — governed
Code-free connector generation
Connect any system without writing adapter code. The system editor supports databases, APIs, LDAP, SSH, SCIM, and more. Define commands, map parameters, configure auth — and the Orchestration Service handles execution, credential management, and proof generation.
SQL Server, Oracle, MySQL, PostgreSQL, and more
LDAP, Active Directory, Entra ID, SCIM
Azure, AWS, SAP, ServiceNow, Jira, Salesforce
SSH, PowerShell, REST APIs, SOAP, custom protocols
connected systems
MCP tools auto-generated
lines of custom adapter code
Why it works: self-describing tools
Connector actions carry CDA x-fields — metadata extensions that make them self-describing enough for three things: workflow composition, safe agent invocation, and zero-shot synthesis.
x-suggest provides valid parameter values so the designer can show dropdowns. x-risk classifies the action so the workflow engine inserts approval gates where needed. The tool carries enough context that the workflow designer knows how to wire it.
x-normalize ensures the agent sends canonical values. x-redact marks sensitive fields for proof-chain privacy. AI context blocks tell the agent when to call the tool, what prerequisites exist, and what not to do.
CDA-enriched schemas give the Zero-Shot engine enough context to compose governed workflows from natural language — without prior training on any specific tool. (Patent pending)
The same OpenID AuthZEN policy evaluates every invocation — whether it comes from a human, a workflow step, or an agent tool call. One policy model across all three surfaces.
How MCP tools are governed
When a connector action becomes an MCP tool, it enters the ARIA MCP Gateway — the governance layer that makes MCP enterprise-safe. Agents connect using standard MCP protocol. The gateway handles everything else.
Policy-scoped discovery
Three layers of filtering: delegation verification (does the agent have this tool?), PDP batch evaluation (does the user's policy allow it?), and attribute-to-use scoping (what data can this delegation reach?). An HR agent sees HR tools. A finance agent sees finance tools. Policy decides.
Schema pinning & integrity
Cryptographically signed schema pins ensure the tool schema hasn't drifted between planning and execution. Four-hour grace windows for zero-downtime upgrades. Signed multi-step plan contracts with per-step parameter fingerprints.
Credential isolation
When an agent calls a tool on behalf of Alice, the gateway retrieves Alice's OAuth token from the vault, uses it for one HTTP call, and discards it. The agent never sees, handles, or stores the token. Per-user attribution, not shared bot accounts.
How the OAuth Vault works →Cryptographic proof per call
Every MCP tool invocation — permit or deny — produces an RS256 JWS-signed receipt. Tamper-evident hash chains, WORM retention, policy snapshots per decision. Receipts, not logs.
Technical deep-dive MCP Gateway architecture, discovery layers, and receipt internals
Transport & Routing
The ARIA MCP Gateway supports HTTP (Streamable HTTP via POST /v1/mcp), WebSocket (WS /v1/mcp/ws), and Server-Sent Events (GET /v1/mcp/sse). Protocol versions: 2024-11-05 through 2025-11-25. The Unified Tool Router dispatches to two backends: tools with full operation metadata route to the Orchestration Service; tools with minimal metadata route to downstream MCP servers. Transparent to the agent.
Three-Layer Discovery
Layer 1 — Delegation Verification: Graph lookup in Neo4j: does the agent have a HAS_CAPABILITY relationship to this tool, and has the user created a delegation? Two-tier caching (3s in-memory, 30s Redis) with Kafka invalidation. Layer 1.5 — Delegation Gate: Does the user's role allow delegating this tool? Enforced via PermissionGrant nodes with operation ref op:agent:tool.delegate. Layer 2 — PDP Batch Evaluation: Every surviving tool evaluated against the delegating user's role via AuthZEN PDP. Layer 3 — ATU Filtering: Runtime constraint enforcement — parameter allowlists, server-side row filters, output token caps, redaction rules.
Virtual MCP Servers
Tools organized into policy-aware server views. Filter-based (dynamic — tools matching source: "jira" auto-included) or explicit (curated lists in YAML). 21 virtual servers pre-defined. A significant extension beyond the MCP spec.
Receipt Chain
Each receipt captures: agent identity, delegating user, tool called, OperationRef, policy constraints, parameter hash (SHA-256 of canonical parameters), schema version, delegation context, and a hash link to the previous receipt. RS256 JWS-signed. WORM retention. Per-agent hash chains — tamper with one, break the chain.
From connector to governed tool — automatically
Every connector operation is automatically published as a governed MCP tool. The publication pipeline generates tool names, typed JSON schemas, authorization requirements, and AI context — so agents know when to call a tool, what prerequisites exist, and what not to do.
System definition with
operations & schemas
MCP tools + workflow nodes
+ AI context blocks
Neo4j catalog with
policy bindings
Policy-scoped via
three-layer filtering
Technical deep-dive Tool generation internals: loopback server, AI context, and catalog sync
Tool Generation
On startup, the Loopback Tool Generator reads all system definitions (YAML) and generates MCP tool definitions with three-segment names: {system}.{object}.{action} (e.g., jira.issue.create). Each tool gets a complete JSON Schema with CDA extensions: x-elicit (mark fields for elicitation), x-suggest (enum options), x-default (sensible defaults), x-default-when (conditional defaults).
AI Context Blocks
Each tool carries an ai_context block: use_when (when to invoke), commonly_used_with (related tools), prerequisites (preconditions), anti_patterns (what NOT to do), and examples (usage samples). The agent doesn't need to reason about when or how to use a tool. The tool tells it.
Catalog Sync
Generated tools registered as (:Tool) nodes in Neo4j with EXPOSES_TOOL and IMPLEMENTS relationships. Auto-assigned to virtual MCP servers. Kafka ToolPublished events fire for analytics and downstream consumers.
What EmpowerNow adds beyond the MCP spec
We implement MCP faithfully. We also extend it where the spec leaves gaps that enterprises can't afford.
Policy-scoped tool catalog views. Agents get curated tool menus based on role, delegation, and tenant — not the full 2,000+ catalog. Not in the MCP spec.
MCP's tools/list returns everything. EmpowerNow adds delegation verification, PDP batch evaluation, and ATU scoping. Each layer can only narrow.
Cryptographic schema integrity with grace windows. Signed multi-step plan contracts with per-step parameter fingerprints.
When a tool call is missing parameters, the gateway pauses and triggers elicitation — the agent prompts the user for missing values, then resumes. Dynamic forms instead of failed calls.
RS256 JWS-signed receipts with per-agent hash chains. WORM retention. Policy snapshots per decision. EU AI Act Article 53 alignment.
PDP-driven egress allowlists with wildcard matching. Blocking of non-whitelisted destinations. Re-verification after HTTP redirects.
Patent-pending architecture
Graph-Anchored Attribute-Based Access Control — hybrid ReBAC+ABAC model via Neo4j membership graph
Zero-Shot AI Workflow Engines — workflow contracts, parameter orchestration, WAITING protocol
Universally-Pluggable Agentic Workflow Engines — MCP facades, multi-agent orchestration, credential non-exposure
See one connector become three governed surfaces
We'll create a connector live, show the action as a workflow node, as an MCP tool in agent discovery, and the same proof chain across all three.