Skip to main content

Cloud Providers: Offering Governed AI as a Platform Service

Cloud providers that offer hosted AI to customers are not shipping one internal assistant. They are operating a platform surface where every tenant expects different retention, residency, tool, and approval rules. The commercial promise is flexible AI access. The operational challenge is making that flexibility governable without building a custom control plane for every customer or market segment.

Keeptrusts helps because it turns governance into part of the platform service contract. Tool Validation constrains what tools a route can expose, Agent Firewall governs tool actions and kill switches, Data Routing Policy filters model targets using provider metadata, and Regulated Execution gives stricter workloads a dedicated operating lane. Combined with Multi-Gateway and Data Residency, that lets a provider sell governed AI as an explicit service feature instead of a soft promise.

Use this page when​

  • You operate a managed AI platform, internal developer platform, or hosted agent service.
  • You need customer-facing controls for tools, provider routing, residency, and reviewability.
  • You want a reusable governance model across commercial, enterprise, and regulated service tiers.

Primary audience​

  • Primary: Technical Leaders
  • Secondary: Platform Engineers, Governance reviewers

The problem​

Platform providers sit in a difficult middle layer. Customers want speed and flexible model choice, but they also want guarantees: no training on their traffic, a specific retention window, region-specific processing, and confidence that agents cannot perform unexpected actions. If those guarantees exist only in product marketing or internal runbooks, the provider is effectively asking customers to trust service behavior they cannot independently verify.

Tool-enabled agent routes make the problem harder. A hosted AI platform may offer retrieval, ticket creation, export, or workflow automation as part of the product. Without declared-tool governance, a route can drift over time. A team adds one more tool for convenience, then another team reuses the same route, and before long the service is exposing capabilities the original customer approval never covered.

Regional and sector differences also matter. A public-sector tenant may need local-only processing and zero retention. A commercial tenant may accept a broader provider pool. If the platform handles those cases with undocumented exceptions instead of a formal control surface, operations and sales eventually collide: the product cannot prove it is honoring the commitment it sold.

The solution​

The right model is to make governance a first-class service primitive. Start with tool declarations. Tool Validation keeps the service honest about what a route can request. It does not validate every tool argument itself, but it does stop undeclared tools and ensures schemas compile, which is the right baseline for a multi-tenant platform.

Then govern the actions. Agent Firewall gives you exact-match allow and deny lists, per-request action caps, simple per-action rate limits, and kill-switch behavior when suspicious patterns or PII appear in tool arguments. That is especially useful for hosted agent platforms where customers expect guardrails around automation, not just around model text.

Provider choice should be explicit as well. Data Routing Policy filters targets according to declared data_policy metadata such as zero retention, no training, retention windows, local-only processing, and tokenized-input support. That creates a real boundary between service tiers instead of a loose internal convention.

Finally, split the runtime by tier when needed. Govern AI Agents and Regulated Execution are useful because they encourage a platform-service design where sensitive workloads are not merely “flagged.” They run through a stricter lane with its own routing and evidence model.

Implementation​

This example shows a governed agent route for a platform-service tier that requires zero retention, declared tools, and strict action caps.

pack:
  name: governed-platform-service
  version: 1.0.0
  enabled: true

providers:
  targets:
    - id: regional-zdr
      provider: openai
      model: gpt-5.4-mini-mini
      secret_key_ref:
        env: OPENAI_API_KEY
      data_policy:
        zero_data_retention: true
        training_opt_out: true
        retention_days: 0
        in_memory_only: true
        sanitized: true
        accepts_tokenized_input: true
        allow_internet_egress: false
        local_only_processing: true

policies:
  chain:
    - tool-validation
    - agent-firewall
    - data-routing-policy
    - audit-logger

policy:
  tool-validation:
    declared_tools:
      - knowledge_search
      - case_create
      - export_csv
    schemas:
      knowledge_search:
        type: object
        properties:
          query:
            type: string
        required:
          - query
      case_create:
        type: object
        properties:
          title:
            type: string
        required:
          - title
    allow_undeclared: false

  agent-firewall:
    allowed_tools:
      - knowledge_search
      - case_create
      - export_csv
    blocked_tools:
      - delete_tenant
    max_actions_per_window: 3
    max_actions_per_session: 10
    rate_limits:
      export_csv: 1
    kill_switches:
      halt_on_suspicious_pattern: true
      halt_on_pii_in_action: true

  data-routing-policy:
    require_zero_data_retention: true
    require_no_training: true
    max_retention_days: 0
    require_in_memory_only: true
    sanitize_before_provider: true
    tokenize_sensitive_fields: true
    allow_internet_egress: false
    local_only_processing: true
    on_no_compliant_provider: block
    log_provider_selection: true

  audit-logger: {}

This kind of pack works well as a premium or regulated service lane. The important point is that the service tier is defined by enforceable runtime behavior, not by a policy PDF. If you need a looser commercial route, create a separate pack with a deliberate change in routing requirements. Do not ask the platform runtime to make those differences implicitly.

Operationally, pair this with regional deployment choices. Multi-Gateway lets teams keep service topology aligned with geography, and Data Residency helps frame how routing commitments should map to actual infrastructure and provider metadata.

Results and impact​

The biggest result is credibility. Sales and solution teams can describe AI governance in service-level terms because the platform has a concrete runtime model behind the claim. Engineering benefits too: new managed routes inherit a known boundary instead of starting from an empty policy file.

This also improves customer onboarding. Rather than debating every tool and provider option from scratch, the provider can present a small number of supported service profiles with documented controls. That reduces exception handling and makes compliance conversations much more concrete.

Finally, the evidence model improves. When customers ask why a request failed or which provider was eligible, the platform can answer from decision events and routing logs instead of reverse-engineering behavior from application traces.

Key takeaways​

  • A governed AI platform service needs enforceable runtime controls, not only contractual language.
  • Tool Validation and Agent Firewall are strong complements for hosted agent routes.
  • Data Routing Policy is what turns provider promises into an actual filter.
  • Use separate packs and lanes for regulated or premium service tiers instead of mixing them with default routes.
  • Regional topology and evidence collection are part of the product, not only of operations.

Next steps​