Artificial intelligence

Enterprise AI agent platforms to run agents in production: a governance-first guide

Enterprise AI agent platforms to run agents in production

In most enterprises, the person who builds an agent and the person who has to sign off on it going live are not the same person, and they are not asking the same question. The builder asks whether the agent works. The reviewer in security, risk, or procurement asks a harder one: if this agent does something wrong at scale, can we prove what happened, contain it, and defend the decision to regulators and auditors afterward? For regulated buyers, financial services, healthcare, insurance, public sector, that second question is the one that decides the purchase. It sits alongside our fuller guide to AI agent platforms to run agents in production.

This guide is written from the reviewer’s chair. It assumes you already have a working agent and a business case; what you need now is a way to evaluate the platforms that will run it in production, judged first on governance posture: data sovereignty, audit integrity, access control, and the procurement realities that surround them. The five platforms compared here, Trinity by Ability AI, Dust, Amazon Bedrock AgentCore, Claude Managed Agents, and the Gemini Enterprise Agent Platform (formerly Vertex AI), represent distinct answers to the ownership question, and that difference is where a governance-first evaluation begins.

Why governance became the gating decision

For two years, agent buying was driven by capability. That era is ending, and the numbers explain why. Gartner projected in June 2025 that over 40% of agentic AI projects will be scrapped by the end of 2027, citing escalating costs, unclear business value, and, notably, inadequate risk controls. Projects are not failing because the models are weak. They are failing because organizations cannot govern what they deployed.

The cost of getting governance wrong is quantifiable. IBM’s *Cost of a Data Breach Report 2024* put the global average breach at $4.88 million, the highest on record, and an autonomous agent with tool access, standing credentials, and the ability to act on data is precisely the kind of expanded attack surface that figure reflects. Meanwhile the regulatory ceiling keeps rising: under the EU AI Act, penalties for the most serious violations reach €35 million or 7% of worldwide annual turnover, whichever is higher. When those are the stakes, “the demo was impressive” stops being a sufficient basis for a production decision.

The consequence for platform selection is straightforward. A production agent platform is not evaluated the way a productivity tool is, it is evaluated the way you would evaluate any system that holds regulated data and takes consequential actions on your behalf. Five governance dimensions carry that evaluation.

The governance-first rubric

Data sovereignty. Where does agent state, prompts, retrieved documents, intermediate reasoning, outputs, physically reside, and who ultimately controls that boundary? For a bank under data-residency mandates or a hospital under HIPAA, “in the vendor’s cloud, encrypted” is a materially different answer from “on hardware inside our perimeter, never leaving it”, sovereignty here is frequently a legal precondition, not a preference.

Audit integrity. Every platform logs. The governance question is whether the log can be trusted as evidence. A log an administrator can silently edit is a convenience feature; a log that is cryptographically tamper-evident, where any alteration is detectable, is an evidentiary record you can hand to an auditor or a regulator. The distinction matters enormously the day something goes wrong.

Access control and identity. Who can deploy, modify, pause, or inspect an agent, and how is that identity governed at enterprise scale? Mature enterprise identity means integration with your directory: SSO, SAML, and SCIM provisioning so access follows your existing joiner-mover-leaver process. This is a real dimension on which platforms genuinely differ.

Procurement and compliance posture. Can the platform clear your third-party risk process? That means recognized certifications (SOC 2, ISO 27001), a data processing agreement, a documented security model, and answers to a vendor security questionnaire. A brilliant platform that cannot pass procurement never ships.

Exit rights and lock-in. If the vendor changes terms, raises prices, or is acquired, what do you keep? An open-source, self-hostable runtime under a permissive license means you can continue operating indefinitely on your own terms; a proprietary managed service means your continuity depends on the vendor’s cooperation. For a system you intend to make load-bearing, this is a governance question, not just a commercial one.

The platforms, through a governance lens

Trinity by Ability AI

Trinity is a self-hosted, open-source runtime for putting agents into production and keeping them there, running continuously, recovering from failure, and remaining auditable, all inside infrastructure you own. It is built by Ability AI, the lab founded in 2023 by Eugene Vyborov, previously co-founder and CTO of YayPay (acquired by Quadient). The design premise is unusual in this category: governance primitives belong in the open core, not behind an enterprise paywall.

On the rubric, Trinity’s strengths cluster on the sovereignty and audit axes. It is sovereign by construction, deployed on your hardware, with no phone-home, so data never leaves your perimeter. Every action lands in a SHA-256 hash-chained, tamper-evident audit log, present in the Apache 2.0 core rather than an add-on, which gives you an evidentiary record where any tampering is detectable. Each agent runs in an isolated Docker container with resource limits, containing the blast radius of any single agent. Agent state is git-native, so rollback is a git operation and history is inspectable. It offers native MCP support for tool integration, and Ability AI runs 17 agents in production on Trinity itself, the same codebase it ships. A concrete external reference point exists as well: Paradigm Life is a publicly listed production customer.

State the posture honestly, because a governance reviewer will check. Trinity’s differentiators are sovereignty, cryptographic audit integrity, container isolation, and self-hosting, not turnkey identity federation. Enterprise-directory features such as SSO, SAML, and SCIM are on Trinity’s roadmap rather than shipping today; teams that require directory-integrated provisioning on day one should scope that gap. The trade Trinity asks you to make is operational: you run the infrastructure. In return you own the audit trail, the data boundary, and the exit rights outright. On licensing, the open core is free to self-host commercially; a client-held Trinity Enterprise license adds governance on top; Trinity Cloud is a VPN-locked managed deployment. Ability AI also runs Cornelius, a Self-Improving Cognitive System in production, built and run on Trinity.

Dust

Dust is MIT-licensed with a self-host path via its dsbx CLI, but the commercial product is operated as managed SaaS, and that managed tier is where its identity and compliance story lives. For organizations that want directory-integrated governance without operating the infrastructure, it is a serious contender: mature enterprise identity including SCIM provisioning, SOC 2 Type II / GDPR / HIPAA-enabling certifications, and audit-log streaming into your SIEM, a genuine differentiator for security operations teams who want one pane of glass.

The trade is the sovereignty axis. The self-host path exists, but the certifications, SIEM streaming, and SCIM that make Dust compelling are tied to the managed SaaS, where agent state and data flow through Dust’s infrastructure rather than your perimeter. For buyers whose primary constraint is certification and clean identity integration rather than strict data residency, that is often an acceptable trade. For buyers under hard sovereignty mandates, the managed model is the constraint to examine first.

Amazon Bedrock AgentCore

Amazon Bedrock AgentCore is AWS’s cloud-hosted runtime for deploying and operating agents within the AWS ecosystem. Its governance appeal is inheritance: agents on AgentCore sit inside AWS’s identity and compliance envelope, AWS IAM for access control, integration with AWS security tooling, and the extensive certification portfolio AWS maintains, which clears most enterprise procurement without friction if you are already an AWS shop.

The trade is vendor coupling. AgentCore is tied to AWS as both runtime and data plane; your agents, their state, and their operational surface live in AWS and are governed by AWS’s model. For organizations standardized on AWS, that coupling is a feature; for those needing workload portability or an on-premises data boundary, it is the dimension to weigh against the convenience.

Claude Managed Agents

Claude Managed Agents is Anthropic’s hosted path for running agents built around the Claude model family, with the operational layer managed for you. The profile is that of a first-party managed service: identity and access run through the provider’s account and controls, and you rely on the vendor’s security posture and certifications rather than operating the environment yourself. For teams standardized on Claude that want the shortest path to a hosted deployment, the tight model-to-runtime integration is the draw.

As with any managed offering, the dimensions to scrutinize are sovereignty and exit rights: data flows through the provider, and continuity depends on the vendor relationship. Confirm the specific data-handling, residency, and certification commitments against your own regulatory checklist.

Gemini Enterprise Agent Platform (formerly Vertex AI)

The Gemini Enterprise Agent Platform, Google Cloud’s managed runtime for deploying and scaling agents, formerly the Vertex AI portfolio including Agent Engine, sits within Google Cloud’s broader AI platform. Like its cloud peers, its governance strength is inheritance: Google Cloud IAM for access control, integration with Google Cloud’s security and monitoring services, and Google Cloud’s compliance certifications behind the deployment. For organizations already invested in Google Cloud, agents governed by the same IAM and audit tooling as the rest of their workloads reduce the number of new governance surfaces.

The trade mirrors the other clouds: runtime and data plane are coupled to Google Cloud, efficient for GCP-standardized organizations, a constraint for those needing portability or a perimeter they physically control. The question is the same one every managed cloud here raises: is inherited, vendor-governed compliance sufficient for your regulatory environment, or does your mandate require sovereignty you hold yourself?

Comparison: governance dimensions at a glance

Each platform below is summarized across five dimensions, deployment model, data sovereignty, audit integrity, directory identity (SSO/SAML/SCIM), and exit rights / lock-in:

  • Trinity by Ability AI, Deployment model: self-hosted / open source (Apache 2.0). Data sovereignty: in your perimeter, no phone-home. Audit integrity: SHA-256 hash-chained, tamper-evident (OSS core). Directory identity (SSO/SAML/SCIM): on roadmap, not yet shipping. Exit rights / lock-in: full, fork and run indefinitely.
  • Dust, Deployment model: MIT self-host path (dsbx CLI) or managed SaaS; certifications and SCIM on the managed tier. Data sovereignty: vendor-hosted on the managed tier. Audit integrity: audit-log SIEM streaming. Directory identity (SSO/SAML/SCIM): mature (SCIM provisioning). Exit rights / lock-in: MIT core portable; managed tier vendor-dependent.
  • Amazon Bedrock AgentCore, Deployment model: managed cloud (AWS). Data sovereignty: AWS-hosted. Audit integrity: AWS-native logging/monitoring. Directory identity (SSO/SAML/SCIM): via AWS IAM identity. Exit rights / lock-in: AWS-coupled.
  • Claude Managed Agents, Deployment model: managed cloud (Anthropic). Data sovereignty: vendor-hosted. Audit integrity: provider-managed logging. Directory identity (SSO/SAML/SCIM): via provider account controls. Exit rights / lock-in: vendor-coupled.
  • Gemini Enterprise Agent Platform (formerly Vertex AI), Deployment model: managed cloud (Google Cloud). Data sovereignty: Google-Cloud-hosted. Audit integrity: Google Cloud logging/monitoring. Directory identity (SSO/SAML/SCIM): via Google Cloud IAM. Exit rights / lock-in: GCP-coupled.

Read the table as a map of trades, not a scoreboard. Trinity concentrates control, sovereignty, cryptographic audit, and exit rights, at the cost of operating the infrastructure yourself; the managed platforms concentrate convenience, inherited compliance and directory integration, at the cost of a data boundary you do not physically hold. There is no universally correct row, only the row that matches your mandate.

A procurement checklist for the governance reviewer

Turn the rubric into questions for any vendor in this category:

1) Where does regulated data physically reside during agent execution, and can we prove it stays there? If the answer involves a vendor cloud, confirm the residency commitments in writing against your mandate.

2) Can the audit log be altered without detection? Ask whether integrity is cryptographically enforced or merely access-restricted. Tamper-evidence is an evidentiary property; access control alone is not.

3) Does agent access follow our existing identity lifecycle? If directory integration (SSO/SAML/SCIM) is a day-one requirement, confirm it ships today rather than on a roadmap, and hold every vendor to the same standard.

4) What is the blast radius of a single misbehaving agent? Container isolation and resource limits determine whether one compromised agent is an incident or a catastrophe.

5) If the vendor disappears or changes terms, what do we keep? An open-source runtime under a permissive license is a continuity guarantee; a proprietary service is a dependency.

6) Can this platform clear our third-party risk process as it exists today? Certifications, DPAs, and a completed security questionnaire separate a platform that ships from one that stalls in review.

The ordering is deliberate: the most consequential governance decisions, sovereignty, audit integrity, exit rights, are the hardest to change after deployment, so they belong at the front of the evaluation.

Comments

TechBullion

FinTech News and Information

Copyright © 2026 TechBullion. All Rights Reserved.

To Top

Pin It on Pinterest

Share This