The Enterprise Agent Control Stack: Six Layers That Must Work Together

Reviewed 17 August 2026 · 15 minute read

An enterprise agent control stack needs six distinct capabilities: identity, decision context, connectivity, transaction authority, controlled execution and outcome evidence. No single identity provider, knowledge graph, gateway, policy engine or payment protocol covers all six. The practical architecture composes those systems and makes one control boundary responsible for the exact action before it reaches a consequential system.

This guide is for enterprise architects deciding where products such as Microsoft Entra, Okta, OriginTrail, Kong, PlainID, Catena and Intelliger fit. It provides a reference control flow, a dated market map and a failure test that exposes gaps which feature lists tend to hide.

What belongs in an enterprise agent control stack?

Start with the questions the system must answer. The answers come from different sources and change at different speeds.

Swipe horizontally to inspect the full diagram.

The layers can run in one platform or several. They remain separate responsibilities even when one vendor supplies more than one.

Microsoft documents Entra Agent ID as an identity foundation for managing agent identities, owners, sponsors, lifecycle, Conditional Access and resource access. That is substantial identity infrastructure. It does not remove the need to bind a purchase amount, destination and approval to one transaction. Microsoft Entra Agent ID documentation makes the identity scope explicit.

Kong's MCP material covers proxying, authentication, access controls, traffic policies, observability and converting existing APIs into MCP tools. Those are gateway responsibilities. A gateway can also call an external authorizer, but it needs a stable transaction object if policy depends on business meaning rather than only route and tool name. Kong's MCP gateway documentation shows the traffic and integration boundary.

The control flow should preserve one transaction identity

A common architectural failure is the loss of meaning between layers. The model proposes a refund for EUR 480, the gateway sees tools/call, the policy engine sees a user and role, and the provider receives a refund request. Every component handled its own object, yet no shared identifier proves they evaluated the same action.

Use a canonical transaction envelope before the authorization decision:

type ControlledTransaction = {
  transactionId: string;
  tenantId: string;
  agentId: string;
  accountableOwner: string;
  action: string;
  resource: string;
  purpose: string;
  counterparty?: string;
  destination?: string;
  amount?: { currency: string; minor: string };
  authorityRef: string;
  contextSnapshotDigest: string;
  requestDigest: string;
  audience: string;
  expiresAt: string;
};

This is an illustrative internal contract, not a standard schema. The security rule is more important than the field names: every transformation must preserve or recompute the fields that change business meaning. If an adapter changes the currency, destination or supplier after approval, the final executor must reject it.

The reference sequence is:

agent proposal
  -> authenticate runtime and resolve owner
  -> retrieve minimum permission-aware context
  -> normalize tool or API request
  -> verify mandate and current policy
  -> obtain independent approval when required
  -> reserve replay, budget and idempotency state
  -> broker a short-lived execution credential
  -> execute against the authoritative provider
  -> reconcile accepted, unknown and terminal outcomes
  -> issue a signed record with explicit assurance limits

The model can interpret intent and propose an action. Deterministic components must enforce authority, money limits, replay, approval binding and credential release.

Where the current market fits

Enterprise agent market positioning

Product-scope analysis, not market share, quality or maturity

Text summary of highlighted companies

Company or protocol	Primary scope represented on the map
Intelliger	Transaction-specific authority, deterministic enforcement, reconciliation and portable evidence.
Concordium	Verified ownership, agent registry and identity-linked transaction infrastructure.
OriginTrail	Shared context graphs, provenance and decentralized knowledge infrastructure.
Okta for AI Agents	Agent identity, lifecycle, access and governance.
Microsoft Entra Agent ID	Enterprise agent identity, ownership, lifecycle and Microsoft ecosystem access.
SailPoint	Agent inventory, ownership, access review and entitlement governance.
Oasis Security	Non-human identity discovery, permissions and just-in-time identity controls.
Aembit	Workload identity and secretless just-in-time access for agents and MCP.
PlainID	Enterprise policy management and distributed authorization enforcement.
Trust3 AI	Purpose controls, grants, traces and data governance.
Kong	LLM, MCP and A2A traffic gateway, authentication and observability.
Portkey	AI and MCP gateway, credential isolation, observability and guardrails.
Cloudflare	Distributed traffic, security, remote MCP and AI gateway infrastructure.
MuleSoft	Enterprise API integration, orchestration and agent-facing connectivity.
Zenity	Agent discovery, runtime threat prevention and security posture.
Astrix	Non-human identity and agent credential risk monitoring.
Catena	Agent financial policy, approvals, accounts, payment execution and audit.
Circle Agent Stack	Programmable wallets, USDC settlement and x402 support.
Google AP2	Typed checkout and payment mandates, role validation and receipts.
UCP	Commerce discovery, checkout, payment-handler and order-lifecycle protocol.
Experian Agent Trust	Consumer identity, intent, fraud and payment trust signals.
BigID	Enterprise data discovery, classification and governance.
Immuta	Data policy, purpose controls and governed access.
AGNTCY	Open agent discovery, identity, messaging and observability infrastructure.

The map is useful only if its axes stay explicit. Moving right does not mean a company is better. A broad identity or gateway platform deliberately solves a wider infrastructure problem. Moving upward does not mean more mature. It means the product's documented scope reaches further into runtime execution, settlement or outcome evidence.

Use the map to identify missing handoffs:

• Identity providers should project a stable subject and owner into transaction policy.
• Context systems should return facts with provenance, access policy and observed time.
• Gateways should normalize the request and enforce the decision before the upstream call.
• Policy engines should evaluate the exact transaction rather than model-written prose.
• Payment and execution providers should return stable references for reconciliation.
• Evidence systems should distinguish the issuer's signed assertion from independently verified business truth.

OriginTrail illustrates why context deserves its own layer. Its DKG V10 repository describes a three-layer memory model, context graphs, RDF query flows and proof mechanisms. The same repository labels V10 a release candidate on testnet and says it is not yet recommended for production workloads. OriginTrail's DKG repository supports both the capability and maturity statements.

Catena shows a different form of overlap. Its current product positions identity, deterministic financial policy, approvals, accounts and multi-rail payments together. For an enterprise that wants an integrated agent banking and governance service, this may reduce integration work. It does not answer every non-financial transaction-control use case, which is why the architecture should compare required control outcomes rather than count features. Catena's product description describes the current banking and governance scope.

How Intelliger fits without replacing the stack

Intelliger's intended role is the transaction-control layer. It consumes identity from enterprise or protocol systems, context from authoritative data sources, policy results from an existing PDP when appropriate and execution from the systems that already own the business action.

The differentiated object is the transaction chain:

identity + owner
  -> bounded mandate
  -> canonical request digest
  -> deterministic decision and approval
  -> provider execution reference
  -> reconciled outcome
  -> portable receipt

This is a better fit when one authority model must cover payment and non-payment actions across several systems or companies, when delegation must not amplify a parent's constraints, or when another party needs to verify a bounded record without access to the issuer's complete log platform.

It is not a reason to replace Entra, Okta, Kong, OriginTrail, PlainID, a payment provider or the customer's knowledge graph. Those systems supply capabilities Intelliger should integrate.

Test the stack with failures, not a happy-path demo

Build one transaction fixture and mutate one property at a time:

{
  "transaction_id": "txn:refund:8421",
  "agent_id": "agent:support:17",
  "action": "refund.create",
  "resource": "order:8421",
  "purpose": "customer_service_resolution",
  "amount": { "currency": "EUR", "minor": "48000" },
  "destination": "original_payment_method"
}

Record which component detects each mutation and whether the provider was called. A stack is incomplete if everyone logs the problem but no component owns the denial.

Operational ownership matters as much as product selection

Assign an owner to every boundary:

• Identity team: agent lifecycle, sponsors, token issuance and emergency disablement.
• Data team: context provenance, field-level access, freshness and deletion.
• Platform team: gateway routing, schema normalization, replay and credential isolation.
• Business control owner: mandate, policy, approval thresholds and exception handling.
• Application or finance team: idempotent execution, provider state and reconciliation.
• Assurance team: evidence retention, historical keys, dispute access and verification policy.

An outage rule belongs beside each owner. A catalog lookup may tolerate cached context. A payment must not silently use stale authority because the policy plane is unavailable. A provider timeout must not become either success or failure until reconciliation establishes the state.

Questions enterprise teams ask about the control stack

Which layer should we implement first?

Start with the action that can create the clearest loss, then trace its identity, context, authority, execution and evidence dependencies. For a payment or production change, identity alone is not a safe first release. The first usable slice should deny an out-of-policy transaction, prevent bypass and reconcile an ambiguous provider response.

Do we need a separate vendor for every layer?

No. One platform may cover several layers, and existing identity, data and gateway products should usually remain in place. The important test is whether each control has an explicit owner and whether information crosses product boundaries without losing tenant, transaction or policy identity.

Can an identity platform provide transaction authorization?

It can provide authenticated identity, lifecycle status, group membership and sometimes coarse entitlements. A consequential transaction still needs limits tied to purpose, resource, amount, destination, time and the exact request. That decision belongs in a transaction-aware authority layer even when the identity platform supplies critical inputs.

Where should evidence live?

Operational logs can remain in the observability platform. Compact signed receipts and their verification material need retention matched to audit and dispute requirements. Keep provider references and reconciliation updates addressable from the same transaction identity instead of copying every sensitive payload into one store.

Current Intelliger and OATI boundary

OATI currently provides a developer-preview framework with public schemas, canonical signing, verification, trust resolution, deterministic mandate evaluation, replay controls, receipts and a 73-case cross-language conformance suite. A hosted trust and lookup vertical slice is deployed, and a reference Envoy authorization path is implemented.

The commercial Enterprise Agent Gateway, full policy compiler, durable evidence and dispute service, complete Hub, independent protocol review and two-enterprise production acceptance are not complete. The broader unified Intelliger platform remains a target commercial architecture built around the shared transaction-control services.

This status matters when comparing established platforms with a developer preview. The chart describes scope, not procurement readiness.

Architecture checklist

• Assign one system of record for agent identity and accountable ownership.
• Retrieve task-specific context with provenance, access policy and observed time.
• Normalize MCP, A2A and API requests into a stable transaction envelope.
• Keep mandate limits separate from current business policy.
• Bind approval to the exact request digest.
• Release credentials only after deterministic authorization.
• Separate proof replay from business idempotency.
• Represent accepted, unknown, confirmed, failed, reversed and disputed outcomes.
• Explain what each signature attests and what it cannot prove.
• Test mutation, bypass, outage, concurrency and reconciliation failures.

For the implementation mechanics, use the AI agent authorization guide, compare enterprise AI agent registry options, compare PlainID with Trust3 AI, compare MCP gateways with API gateways and review the AI agent audit-trail model.

Expert review required before publication: identity, gateway, payment and protocol specialists should validate the product-scope coordinates, source interpretations and current-versus-target statements.

To test one bounded transaction across your existing stack, review the Agent Trust architecture and contact Intelliger.