The architectural split that matters
The external agent can live anywhere: your own cloud, the customer network, or a partner-hosted runtime. ADI does not have to execute the agent to govern it.
The relying system has two separate jobs. First it must authenticate the caller technically. Then it must ask ADI whether that authenticated agent is allowed to act for this owner, in this scope, under this trust level.
Authentication answers: is this request technically authentic?
ADI trust answers: who is this agent, for whom may it act, and what is currently allowed?
Mode 1: Agent token or API key plus trust lookup
This is the most direct pattern for internal systems or fast enterprise integrations. The external agent authenticates with an agent token or API key, and the relying system immediately asks ADI for the live trust state before executing the action.
Best for internal owner systems and private tools
No OIDC federation required
ADI remains the source of truth for permissions, limits, and revocation
Standard mode sequence
The relying system trusts its own runtime authentication and then asks ADI for the binding, policy, and certificate state.
sequenceDiagram
participant A as External Agent
participant S as Owner Internal System
participant T as ADI Trust Layer
A->>S: Request + agent_token or API key
S->>T: Read trust profile and verification state
T-->>S: Identity, ownership, delegation, certificate state
alt Policy allows action
S-->>A: Access granted
else Policy blocks action
S-->>A: Access denied
end Mode 2: OIDC plus trust lookup
Some enterprise systems already require OIDC at the gateway or application boundary. In that case ADI can provision a standard Keycloak confidential client for the agent, the agent can fetch an OAuth2 client_credentials token, and the relying party can validate that token through standard discovery and JWKS.
OIDC still does not replace ADI. It covers the transport-side authentication step, while ADI remains the source of truth for delegation, ownership, certificate state, and revocation.
Best for enterprise IAM landscapes
Uses standard OIDC discovery, JWKS validation, and OAuth2 client_credentials
ADI remains mandatory for delegated authority checks
Enterprise mode sequence
OIDC validates the access token, but the final authorization decision still depends on the ADI trust lookup.
sequenceDiagram
participant A as External Agent
participant I as ADI Keycloak or Enterprise Gateway
participant S as Enterprise System
participant T as ADI Trust Layer
A->>I: Request client_credentials token
I-->>A: Access token
A->>S: Request + OIDC token
S->>S: Validate token locally or at gateway
S->>T: Resolve agent trust and delegation
T-->>S: Trust decision
S-->>A: Access granted or denied Mode 3: Signed delegation credential plus trust lookup
For higher-trust actions such as sensitive purchases, payment approvals, or regulated delegations, the agent can present a signed delegation credential or a signed request envelope. The relying system validates the signature and then checks the backing certificate and delegation state against ADI.
Best for regulated or high-value actions
Needs relying-party signature validation
Becomes strongest after human identification and AdES or QES issuance
High-trust mode sequence
Cryptographic proof strengthens the request, but ADI still supplies live status, revocation, and delegation truth.
sequenceDiagram
participant A as External Agent
participant S as Relying System
participant T as ADI Trust Layer
A->>S: Signed request + delegation credential
S->>S: Verify signature or credential envelope
S->>T: Check certificate binding, delegation, and revocation state
T-->>S: Trust result
alt Trust and policy both valid
S-->>A: Action executed
else Trust invalid or revoked
S-->>A: Action denied
end How to choose without overengineering
Most teams should begin with the standard mode and only move upward when the relying system or compliance context truly demands it. The mistake is not starting simple. The mistake is collapsing authentication and trust into one ambiguous mechanism.
Standard first for speed and control
OIDC when enterprise infrastructure already expects it
Signed delegation when the action itself needs stronger proof
Decision map
Start with the simplest mode that satisfies the relying system and the accountability level of the action.
flowchart TD
start["External agent wants to act"] --> q1["Does the relying system already require OIDC?"]
q1 -->|No| standard["Use agent token or API key + ADI trust lookup"]
q1 -->|Yes| oidc["Use OIDC + ADI trust lookup"]
standard --> q2["Is cryptographic non-repudiation required?"]
oidc --> q2
q2 -->|No| done["Live trust decision from ADI is enough"]
q2 -->|Yes| signed["Add signed delegation credential + ADI trust lookup"]