Where should governance enforcement points be implemented within enterprise…

Research Question

Where should governance enforcement points be implemented within enterprise architecture for Artificial Intelligence (AI) and low-code systems, specifically, at which architectural layers (Application Programming Interface (API) gateways, data access layers, orchestration engines, or model runtimes) should controls be placed, what types of controls are appropriate at each layer (allow or deny policies, rate limits, content filters, action constraints), and how should conflicts between enforcement layers be resolved?

Findings

(Populated from §6 Synthesis above.)

Executive Summary

• Enterprise AI and low-code governance should be enforced as a layered architecture in which gateways handle ingress identity and traffic controls, data systems remain authoritative for resource access, orchestration engines constrain tools and actions, and model runtimes apply semantic safety filters, because no single layer can enforce all four classes of control reliably.
• Gateway-only or runtime-only enforcement is insufficient, because best-effort quotas, stale permission copies, direct-publication paths, and unmanaged connectors each create bypass routes that only another layer can close.
• Conflicts between layers should resolve through canonical policy authoring plus fail-closed priority rules, with authoritative resource or identity denies never overridden downstream and local exceptions translated from the canonical policy source rather than hand-edited at enforcement points.
• The strongest defense-in-depth pattern is selective duplication across layers that address different bypass vectors, especially for identity, rate control, action constraint, and auditability, because agentic execution amplifies the blast radius of any single missed control.

Key Findings

1. Confidence: high. Gateway layers should enforce ingress identity checks, coarse authorization, protocol normalization, schema validation, and rate controls because they intercept managed calls before business logic runs and expose the broadest set of transport-level controls across vendors.
2. Confidence: high. Data-access layers must remain authoritative for classification, row or document access, and resource-owner deny decisions because every upstream layer depends on their identity and permission semantics and cannot safely reconstruct them from partial metadata.
3. Confidence: high. Orchestration engines and low-code runtimes are the correct layer for tool allowlists, connector restrictions, approval checkpoints, and deployment gates because they govern executable workflow state transitions rather than only raw network traffic.
4. Confidence: high. Model-runtime enforcement is best reserved for prompt and response safety, masking, groundedness, jailbreak detection, and provider-facing trust controls because those checks require semantic visibility into generated content that gateways and data stores do not possess.
5. Confidence: medium. Rate limiting should be applied at both gateway and orchestration or execution layers when autonomous agents can loop or fan out, because gateway quotas alone may be best-effort, topology-dependent, or blind to internal tool recursion.
6. Confidence: high. Cross-layer policy conflicts should be resolved by canonical policy authoring plus explicit priority ordering, not by ad hoc local overrides, because selective defense in depth becomes policy drift unless every layer-specific rule is translated from one authoritative source.
7. Confidence: high. The main bypass vectors are direct backend access, stale permission copies, direct maker publication, unmanaged connectors, and alternate model entry points, so each enforcement layer needs a paired compensating control at another layer instead of standing alone.
8. Confidence: high. Major enterprise platforms converge on the same layered pattern even though their products differ, which means a multi-vendor enterprise should design around control-surface roles rather than around any one vendor's product boundary.
9. Confidence: high. Selective duplication of controls across layers adds value only when each layer addresses a distinct bypass vector or failure mode, because duplicating the same logical rule without canonical translation creates policy drift instead of stronger protection.

Assumptions

• Assumption: Salesforce Einstein Trust Layer capabilities cited here still reflect current production controls. Justification: claims were limited to the broad control categories that Salesforce's official help material described directly.
• Assumption: OPA-style decoupled policy patterns are applicable to AI and low-code orchestration surfaces even when a vendor does not expose OPA directly. Justification: the evidence establishes the architectural pattern of separated decision and enforcement, not a requirement to deploy OPA itself.

Analysis

• The evidence weighs most strongly toward role separation by control surface, because zero-trust and decoupled-policy sources both reject the idea that one location can faithfully hold all governance logic.
• Gateway evidence is strong on ingress control but weaker on hard guarantees for autonomous rate management, so rate control was treated as additive rather than gateway-exclusive.
• Data and identity layers were weighted as authoritative because adjacent completed items already showed that copied permission state and borrowed human identity are major failure mechanisms when treated as substitutes for source truth.
• Orchestration controls were treated as first-class rather than optional because low-code systems fail through connector choice, trigger configuration, and unmanaged promotion paths that neither gateways nor runtimes can fully constrain.
• Runtime safety evidence is strong on semantic filtering and weak on business authorization, so the conclusion deliberately narrows runtime responsibilities to safety and trust functions rather than broader enterprise authorization.

Risks, Gaps, and Uncertainties

• Power Platform policy propagation is not instantaneous, so there is a residual timing window between policy authoring and full low-code runtime enforcement.
• Amazon API Gateway usage-plan throttling is best-effort, so enterprises that need hard rate guarantees need compensating controls beyond usage plans alone.
• Salesforce-specific runtime-control detail remains less explicit in the reviewed evidence than the Microsoft and AWS documentation, so Salesforce claims were kept general and should be deepened with additional product documentation if the architecture will rely on Einstein-specific controls.
• Policy distribution latency and translation drift remain material risks in any distributed layered model unless policy promotion, rollback, and verification are automated.

Open Questions

• What policy-translation workflow best converts one canonical governance rule into gateway, workflow, and runtime artifacts without human copy-and-paste drift?
• How small can the low-code policy-propagation window become in practice under enterprise scale, and what compensating controls are realistic during that window?
• Which rate-control design offers the best combination of hard guarantees, operational cost, and cross-vendor portability for autonomous agents that can recurse or fan out internally?

sources

• [x] NIST Special Publication (SP) 800-207, Zero Trust Architecture — - primary architecture source for policy decision, policy administration, and policy enforcement separation.
• [x] Azure API Management policy reference — - gateway control catalog covering rate limits, identity validation, content checks, request transformation, and logging.
• [x] Azure API Management policy overview and scopes — - policy ordering, inbound or outbound sections, scope inheritance, and parent-policy composition.
• [x] Amazon API Gateway resource policies — - resource-based gateway authorization by principal, Internet Protocol (IP) range, Virtual Private Cloud (VPC), and endpoint.
• [x] Amazon API Gateway usage plans — - throttling and quota controls, with AWS's note that quotas are best-effort and not authorization.
• [x] Open Policy Agent (OPA) documentation root — - decoupled policy engine and multi-surface enforcement scope.
• [x] OPA philosophy — - policy decoupling rationale and applicability across gateways, services, and pipelines.
• [x] OPA bundle management — - distributed policy publication and eventual-consistency constraints.
• [x] Microsoft Foundry content filtering for models — - current Microsoft source for runtime content filtering, prompt-attack detection, and protected-material checks.
• [x] Azure OpenAI default safety policies in Microsoft Foundry — - default prompt and completion guardrails, protected material checks, and jailbreak detection.
• [x] Amazon Bedrock Guardrails — - model runtime safeguards including content filters, denied topics, sensitive-information checks, grounding, and automated reasoning.
• [x] Kong plugin hub — - current Kong source for available gateway and AI-oriented plugin control surfaces.
• [x] Kong rate limiting plugin — - gateway-layer throttling strategies and accuracy trade-offs.
• [x] Power Platform data policies overview — - low-code connector, tool, trigger, and runtime suspension controls.
• [x] MuleSoft API Manager policy overview — - API-level security, traffic, and service-level access enforcement without code changes.
• [x] MuleSoft rate limiting policy — - gateway throttling by identifiers and execution-window behavior.
• [x] Salesforce Einstein Trust Layer overview — - official Salesforce trust layer source discovered during investigation and used for masking, audit, and provider-retention claims.