Documentation
03 — Integration matrix (the 11 targets)
Project-Agent / control-plane-evaluation/03-integration-matrix.md
The hardest part of this platform is integrating with seven commercial agent fabrics and four open frameworks. For each target: integration mechanism (specific), the minimum data we extract, the minimum control we push in, brittleness rating (1 lowest, 5 highest), and the partner-relationship reality.
The headline scoring table is at the top. Per-target briefs follow.
---
Headline scoring
| # | Target | Integration mechanism (primary) | Discovery | Identity binding | Policy enforcement | Kill switch | Brittleness | Partner reality | |---|---|---|---|---|---|---|---|---| | 1 | Salesforce Agentforce | Apex managed package + Tooling API | ✓ via Tooling API | binder only | in-Apex action hook | Tooling API flow disable | 3 | Certified partner program; doable but ISV review takes 8–14 weeks | | 2 | Microsoft Foundry / Copilot Studio | Microsoft Graph + Foundry SDK + Entra app + Azure Marketplace | ✓ via Graph | binder only | egress proxy + Graph hook | Graph agent disable | 4 | Certified Microsoft partner only; ISV review + Marketplace gating | | 3 | Google Gemini Enterprise Agent Platform | Google Cloud Asset Inventory + Gemini Agent Builder API + Workspace Admin SDK | ✓ via Asset Inventory | binder only | egress proxy + Builder API hook | Builder API disable | 4 | Cloud Marketplace listing; Google Workspace Admin permissions are coarse | | 4 | AWS Bedrock AgentCore | Bedrock GetAgent/ListAgents + EventBridge + IAM Identity Center | ✓ via Bedrock APIs | binder + STS chained role | egress proxy + Bedrock action group hook | Agent prepare-with-disabled | 3 | AWS Partner Network; STS chained roles work as a lever | | 5 | ServiceNow AI Agents | Now Platform REST + Flow Designer custom action | ✓ via REST | binder only | in-flow action hook (custom Flow step) | Flow pause via REST | 2 | ServiceNow Store listing; mature partner ecosystem | | 6 | UiPath | Orchestrator REST + Studio activity NuGet + Insights | ✓ via Orchestrator REST | binder only | activity-level Studio package | Job-stop API | 2 | UiPath Marketplace; activity packages are easy to ship | | 7 | IBM watsonx Orchestrate | watsonx Orchestrate REST + skill SDK | ✓ via REST | binder only | skill-wrapper at registration | Skill disable via REST | 3 | IBM partner program; smaller install base | | 8 | LangChain / LangGraph | Python SDK middleware (@langchain.callbacks + LangGraph node hooks) | inferred from code/runtime | full SVID binding | in-process PEP | runtime termination | 2 | OSS — no partner needed; LangChain Inc. is a friendly competitor on observability | | 9 | CrewAI | Python SDK middleware (tool_use_callback + crew-level hook) | inferred from code/runtime | full SVID binding | in-process PEP | runtime termination | 2 | OSS — no partner needed | | 10 | AutoGen | Python SDK middleware (AssistantAgent + register_function wrapper) | inferred from code/runtime | full SVID binding | in-process PEP | runtime termination | 3 | OSS — Microsoft Research project; volatile API | | 11 | OpenAI Agents SDK | Python SDK middleware (agent_hooks + tool_executor wrapper) | inferred from code/runtime | full SVID binding | in-process PEP | runtime termination | 3 | OSS — but fast-moving; OpenAI has commercial agent fabric ambitions that may compete |
Reading the table:
- Brittleness 1 = stable public API, well-documented, low risk of breaking change. 5 = no public API, must reverse-engineer or be inside the vendor.
- "binder only" under identity binding = ARX maintains the (ARX-SVID ↔ platform-native-identity) mapping; ARX cannot replace the platform's native identity. This is the realistic posture for all seven commercial platforms.
- "in-Apex action hook" / "in-flow action hook" / "skill-wrapper at registration" all = code that runs on the target platform that calls back to ARX's PDP. Each is bespoke per-platform engineering.
- "egress proxy" = ARX intercepts the target platform's outbound network calls. Limited fidelity (no prompt visibility unless ARX is also the LLM-API destination, i.e., the customer routes their LLM calls through ARX).
---
1 — Salesforce Agentforce
- Integration mechanism:
- Discovery: Tooling API
SELECT Id, DeveloperName, Type, Status FROM Agent(Salesforce Agentforce metadata). Plus Event Monitoring (AgentSession,AgentToolInvocationevents) for behavioral inventory. - Identity: Connected App with OAuth 2.0 client credentials flow + per-named-credential scoping. ARX maintains
(arx-svid ↔ Salesforce User ID)mapping. - Enforcement: Apex managed package with a
Before Actiontrigger onAgentActionthat calls out to the ARX PDP via Named Credential. Returns Permit/Deny synchronously (Salesforce callout 120s timeout but practical 5–10s budget). For ESCALATE, returns Deny with aholdReasonthat surfaces in the Agentforce UI for human approval. - Kill switch: Tooling API
PATCH AgentAction.Status = 'Inactive'+ Event Monitoring stream confirms cessation. - Minimum data out: agent definition (Tooling API), tool calls (Event Monitoring), action results (Event Monitoring), human-owner mapping (User table).
- Minimum control in: Apex package callout for PEP, Tooling API for kill switch, Connected App for credential issuance.
- Brittleness: 3. Apex managed packages are stable but require ISV partner review (Salesforce Security Review — 8–14 weeks first time). Tooling API is stable. Event Monitoring requires Shield ($) so not all customers have it.
- Partner reality: Salesforce ISV partner program. ARX needs a managed package listed on AppExchange. Multi-month review the first time, faster after. Salesforce is friendly to security ISVs (they have a strong security partner ecosystem) but they will compete on this exact use case eventually with their own Trust Layer extensions.
---
2 — Microsoft Foundry / Copilot Studio
- Integration mechanism:
- Discovery: Microsoft Graph
/agents,/copilots(Copilot Studio agents). Foundry tenant audit log via Graph + Microsoft Purview audit search. - Identity: Entra app with delegated + application permissions. Federated managed identity for the credential flow. ARX maps
(arx-svid ↔ Entra service principal ↔ Foundry agent ID). - Enforcement: Two paths.
- For Copilot Studio (low-code): a custom connector in the Power Platform that wraps every action; the agent's flow calls through the connector. Workable but every agent author has to use it.
- For Foundry pro-code agents: an egress proxy (the customer's Foundry runtime egresses through ARX) for tool/LLM calls — limited fidelity. Plus Graph webhook on
agentActionExecutedfor after-the-fact audit. - Kill switch: Graph
PATCH agent/{id} disabled=true+ Power Platform DLP policies as a fallback that block the connector. - Minimum data out: agent metadata (Graph), action logs (Purview audit), tool calls (egress proxy or Power Platform connector).
- Minimum control in: custom connector + Graph + DLP policy.
- Brittleness: 4. Microsoft Graph is stable but Foundry-specific surfaces are evolving fast (this is a 2024–2025 product area). Power Platform DLP works but is coarse. Egress proxy in Azure-hosted Foundry runtimes requires customer to route Foundry egress through ARX — operationally non-trivial for some.
- Partner reality: Microsoft Solutions Partner status + Azure Marketplace listing + ISV co-sell. Microsoft will be friendly and competitive — Defender for Cloud Apps + Purview are moving into agent governance.
---
3 — Google Gemini Enterprise Agent Platform
- Integration mechanism:
- Discovery: Google Cloud Asset Inventory
cloudasset.assets.searchAllResourcesfiltered to Gemini Agent Builder resources. Workspace Admin SDK for Workspace-scoped agents. - Identity: GCP service account + workload-identity federation for cross-cloud SVID acceptance. ARX maps
(arx-svid ↔ GCP SA email). - Enforcement: Two paths.
- Agent Builder offers function-calling — wrap each tool registration with an ARX-aware proxy function that calls back to PDP.
- Egress proxy fallback for Gemini API calls (the customer's VPC egress for Gemini routes through ARX).
- Kill switch: Agent Builder agent disable via API + IAM service-account disable as defense in depth.
- Minimum data out: agent definitions (Asset Inventory), tool registrations + calls (Agent Builder), Gemini API call destinations (egress proxy).
- Minimum control in: wrapped function registrations + IAM disable.
- Brittleness: 4. Same maturity issue as Foundry — Google Gemini Enterprise Agent Platform is rapidly evolving. APIs likely to change quarterly.
- Partner reality: Google Cloud Marketplace + Built with Gemini partner status. Less mature partner program than AWS. Google is friendly but distracted; their own Agent Space governance will eat into this if/when it ships.
---
4 — AWS Bedrock AgentCore
- Integration mechanism:
- Discovery: Bedrock
ListAgents,GetAgent,ListAgentVersions. EventBridge bus on Bedrock-emitted events. - Identity: IAM Identity Center + STS chained roles. ARX assumes a customer role; mints scoped session credentials per agent action. SVID mapping:
(arx-svid ↔ Bedrock agent ARN ↔ underlying IAM role). - Enforcement: Two paths.
- Action groups (Bedrock's tool-call mechanism) can be Lambda-backed — wrap the Lambda with an ARX layer that calls back to PDP. Native and clean.
- Egress proxy fallback for non-action-group LLM/tool calls (PrivateLink-routed Bedrock egress through an ARX VPC endpoint).
- Kill switch:
PrepareAgentwith action groups disabled;DeleteAgentAliasfor prod aliases; IAM-level role disable as defense. - Minimum data out: agent definitions (Bedrock APIs), action group invocations (CloudTrail + EventBridge), prompts/completions (Bedrock model invocation logs if enabled by customer).
- Minimum control in: Lambda layer for action groups + Bedrock prepare/delete API + IAM.
- Brittleness: 3. Bedrock APIs are stable. EventBridge is stable. Lambda layer pattern is well-established. The dependency on customer enabling model invocation logging is the weak spot.
- Partner reality: AWS Partner Network (APN) Advanced Tier, ideally Competency-status. AWS is the friendliest of the three hyperscalers to security ISVs; this is the lowest-risk hyperscaler partnership.
---
5 — ServiceNow AI Agents
- Integration mechanism:
- Discovery: REST
Table APIagainstsn_aia_agentandsn_aia_agent_actiontables. - Identity: OAuth 2.0 client credentials with ServiceNow Instance Auth. ARX maps
(arx-svid ↔ ServiceNow sys_user). - Enforcement: Custom Flow Designer step that wraps
AI Agent Actionexecution; the step calls out to ARX PDP synchronously. Returns Permit → action proceeds. Deny → action rejected with reason. Escalate → flow pauses, ARX surfaces approval, customer's existing ServiceNow Approval framework can be reused. - Kill switch: REST API to set agent state to Inactive + Flow Designer pauses any in-flight flows referencing the agent.
- Minimum data out: agent definitions (Table API), action invocations (sys_audit + Now Assist Skill Kit telemetry), prompts (Skill Kit logs if enabled).
- Minimum control in: Flow Designer custom action + REST API for kill.
- Brittleness: 2. ServiceNow APIs are very stable; ServiceNow ISV apps are well-supported.
- Partner reality: ServiceNow Store listing + Built On Now certification. Mature program. ServiceNow is friendly and the Now Platform is one of the most ISV-friendly enterprise platforms.
---
6 — UiPath
- Integration mechanism:
- Discovery: Orchestrator REST
/odata/Robots,/odata/Processes,/odata/Releases. Insights API for behavior. - Identity: External Application OAuth 2.0 client credentials. ARX maps
(arx-svid ↔ UiPath robot identity). - Enforcement: Studio activity package (NuGet) that wraps every "AI step" (LLM call, tool call) with a callback to ARX PDP. Activity is mandatory if the customer's Governance settings require it.
- Kill switch: Orchestrator
Job/StopJobs+Robot/Disable. - Minimum data out: robot/process inventory (REST), execution telemetry (Insights), activity invocation (custom activity logs).
- Minimum control in: custom activity for PEP + Orchestrator API for kill.
- Brittleness: 2. UiPath APIs and the activity SDK are very stable.
- Partner reality: UiPath Marketplace listing. Mature program. UiPath is migrating to AI-native (Maestro), so the activity-package model may evolve, but legacy paths stay supported.
---
7 — IBM watsonx Orchestrate
- Integration mechanism:
- Discovery: watsonx Orchestrate REST
/skills,/agents. AI Gateway audit for invocation telemetry. - Identity: OAuth 2.0 with IBM Cloud IAM API key. ARX maps
(arx-svid ↔ watsonx skill ID ↔ IBM Cloud IAM service ID). - Enforcement: Skill wrapper at registration time (every skill is registered with a wrapper that calls ARX PDP before delegating to the underlying skill action).
- Kill switch: REST API to disable skill + AI Gateway policy update.
- Minimum data out: skill inventory + invocation telemetry.
- Minimum control in: skill wrapper + REST disable.
- Brittleness: 3. watsonx Orchestrate has a smaller install base than the other six; less battle-tested. IBM partner programs are mature.
- Partner reality: IBM Embedded Solution Agreement + watsonx Partner Plus. Slow but achievable.
---
8 — LangChain / LangGraph
- Integration mechanism:
- Discovery: not from the framework itself (it's a library, not a platform) — discovery is via runtime egress observation (C1.2) and via the customer adding ARX SDK.
- Identity: ARX SDK obtains a JWT-SVID for the agent at startup; full SPIFFE binding (the only category of target where this is realistic).
- Enforcement: in-process PEP. ARX ships a
from arx_langchain import GovernedAgent, GovernedTool, GovernedRunnable. All tool calls and LLM calls are intercepted via LangChain's callback handler API. - Kill switch: at the framework level, raise
ARXTerminatedExceptionfrom any active callback. Any process running the agent crashes its current invocation; the runtime handles re-entry per the customer's job system. - Minimum data out: tool calls + LLM calls + intermediate steps via callbacks.
- Minimum control in: in-process via wrapper classes.
- Brittleness: 2. LangChain's callback API is stable; LangGraph's node-hook API is newer but stable.
- Partner reality: none required (OSS, MIT). LangChain Inc. is a competitor on observability (LangSmith) but not on governance. Friendly enough.
---
9 — CrewAI
- Integration mechanism:
- Discovery: same as LangChain (runtime + SDK).
- Identity: SDK obtains JWT-SVID; full SPIFFE binding.
- Enforcement: in-process PEP. ARX ships a
from arx_crewai import GovernedCrew, governed_tooldecorator. Tool-use callbacks intercept every action. - Kill switch: same pattern as LangChain.
- Minimum data out: crew composition + agent task delegations + tool calls.
- Minimum control in: in-process wrappers.
- Brittleness: 2. CrewAI is younger than LangChain but has a clean, stable callback API.
- Partner reality: none (OSS). CrewAI Inc. has commercial offerings but doesn't compete on governance.
---
10 — AutoGen
- Integration mechanism:
- Discovery: same as LangChain (runtime + SDK).
- Identity: SDK obtains JWT-SVID; full SPIFFE binding.
- Enforcement: in-process PEP. ARX ships a
from arx_autogen import GovernedAssistantAgent, governed_register_function. Wraps everyregister_functioncall and every nested-conversation step. - Kill switch: cancel the active
ConversableAgent.sendvia injection of a sentinel message + raise. - Minimum data out: agent message history + function calls + nested-team delegations.
- Minimum control in: in-process wrappers.
- Brittleness: 3. AutoGen is Microsoft Research; the API has changed significantly in v0.4 (they did a major rewrite). High volatility risk.
- Partner reality: none (OSS, MIT). Microsoft owns AutoGen — no separate partnership but Foundry's competitive posture applies.
---
11 — OpenAI Agents SDK
- Integration mechanism:
- Discovery: same as LangChain (runtime + SDK).
- Identity: SDK obtains JWT-SVID; full SPIFFE binding.
- Enforcement: in-process PEP. ARX ships an
arx_openai_agentspackage wrappingAgent,Runner, and thetooldecorator with PDP callbacks. - Kill switch: tear down the active
Runnervia thelifecyclehook. - Minimum data out: agent definition + tool calls + handoffs (multi-agent) + traced runs.
- Minimum control in: in-process wrappers.
- Brittleness: 3. OpenAI Agents SDK is new; API will change. Also, OpenAI is launching commercial agent surfaces that will eventually compete with Salesforce/Microsoft for the same buyer.
- Partner reality: none (OSS, MIT). OpenAI has commercial agent ambitions; the moment they ship a managed agent platform with native governance, this becomes a "compete with the source" dynamic.
---
Targets that are likely impossible without an inside-the-vendor relationship
Three are real risks:
Risk 1 — Microsoft Foundry pro-code agents
The egress-proxy fallback works but has limited fidelity (cannot inspect prompts at the transport layer; only LLM-API destinations and structured tool-call args). To get prompt-level visibility for pro-code Foundry agents, ARX needs either the customer to route their LLM API calls through ARX (works only if ARX is the customer's preferred LLM proxy, which is a separate sale) or Microsoft to allow third-party hooks at the action-execution level. The latter currently requires a Microsoft partnership at Embedded ISV / Co-sell tier.
Customer mitigation if no Microsoft partnership: ARX governs the action surface (what tool was called with what arguments) but not the prompt content. Customer's own Microsoft Purview + Defender for Cloud Apps takes the prompt-side coverage. Position as complementary.
Risk 2 — Google Gemini Enterprise Agent Platform pro-code agents
Same shape as Foundry. Egress proxy + Gemini Agent Builder function-call hooks cover the action surface; prompts require ARX-as-LLM-proxy or Google partnership.
Customer mitigation if no Google partnership: same as Microsoft — government action coverage; pair with Google's own Agent Space governance.
Risk 3 — AWS Bedrock AgentCore without customer-enabled model-invocation logs
Bedrock model invocation logging is opt-in per AWS account. If the customer hasn't enabled it, ARX cannot see prompts/completions even with full Bedrock partnership. Action-group invocations are visible via CloudTrail (always on); LLM-call content requires the customer to flip the log setting on.
Customer mitigation: require model-invocation-logging-enabled as a pre-requisite for full coverage; document the degraded-coverage mode for customers who can't enable it (regulated industries sometimes resist additional cloud-side data retention).
What to do for customers who use these without coverage
For all three: ship the degraded-coverage mode explicitly, document what is and isn't covered, surface the gap on the Board View. Do not paper over it. Sophisticated CISO buyers will notice and will lose trust if the gap is hidden.
---
Honest pushback (per the workflow)
The integration matrix above assumes ARX gets accepted into all seven commercial-platform partner programs. Some won't accept — at least one of (Microsoft, Google, OpenAI) will probably treat ARX as a competitor by mid-2027 once their own governance offerings ship.
The defensive posture: ARX's value isn't being the only governance layer for any one platform — the value is being the only one that works across all eleven. A Cisco, a JPMorgan, a Pfizer running agents on six of the seven commercial platforms doesn't want six different governance vendors. ARX wins the procurement on consolidation, even if any individual platform vendor would prefer the customer use that platform's first-party tooling.
The risk this turns into: each platform vendor is content with ARX governing other platforms' agents but adversarial about ARX governing theirs. This is a partner-relationship management discipline — keep the customer in the seat and let the customer require each platform to play nice. Don't fight platform vendors directly.