Tier-3 Hybrid Architecture
Agent / tunnel / in-process execution — sovereignty plus secret handling.
The architecture in one picture
The control plane (software-as-a-service) and the agent (running in the customer's virtual private cloud, or VPC) are the only two processes that talk to each other over the internet. System credentials stay in the agent vault — the payloads sent from the control plane to the agent never contain secrets.
The sovereignty problem
Mid-market EU customers want the scale of a SaaS identity governance product, but they do NOT want their system credentials (API keys, LDAP bind DNs, OAuth secrets) landing in a foreign cloud. A pure-SaaS product forces this trade-off; a pure on-premises product costs them the SaaS scale.
RapidValue's answer is the tier-3 hybrid model: the control plane (the interface, workflows, advisor, and audit trail) runs as SaaS, a lightweight agent inside the customer VPC handles all system input/output, and every secret stays in the customer's own vault.
Three execution modes per system
Every connected system has an execution_mode setting:
-
in_process — the control plane runs system calls directly. This is the default for SaaS-only customers with no sovereignty requirement (test and development tenants, marketing-side integrations).
-
agent — a full proxy: every system method (listing users, granting a group, and so on) goes through the task queue to the agent. This is the default for proof-of-concept (POC) tenants and all on-premises integrations. The agent resolves credentials locally from
agent-vault.json. -
tunnel — the system's code runs on the control plane (typically REST or SCIM), but the HTTP transport is routed through the agent. This suits targets whose API is only reachable from inside the customer VPC, while the system logic itself does not need to be sovereign. LDAP and Active Directory are hard-blocked in tunnel mode — raw TCP is physically impossible to proxy over HTTP.
The secret-handling rule
Secrets NEVER travel over the wire from the control plane to the agent. The payload for a task carries only configuration (engine type, base URL, engine config). Authentication is resolved on the agent side through SecretRef references that the agent looks up in its vault.
Since bring-your-own-vault v2 (2026-06-29) there is a per-tenant registry of secret backends (zero or more per tenant); a system binds to one backend. agent_local backends never store secrets centrally — resolution happens inside the tier-3 agent, and the secret never crosses the wire. read_only backends let the customer supply a reference themselves, which the platform only resolves. The API never returns a secret value — only its resolution status.
⚠ Note
If you ever see credentials in a log line taken from the wire payload during debugging, something is structurally wrong. Open a security ticket — this touches the number-one EU sovereignty promise.
Tunnel server-side request forgery guard
Every http_request task carries an allowed_base_url (equal to the system's base_url). The agent refuses any request whose URL does not match that prefix — preventing a compromised control plane from using the agent as a general-purpose proxy into internal services (a server-side request forgery, or SSRF, attack).
Enterprise agent — four additional capabilities
Tier-3 agents can enable four production-grade features that bring parity with commercial governance products (Omada and others):
- Keypair authentication — ECDSA P-256 challenge-response instead of a bearer token, with anti-replay protection through one-shot nonces.
- WebSocket push — task latency drops from roughly 25 seconds (long-poll) to near-zero, with a REST fallback.
- Supervisor process — automatic restart on crash with exponential backoff and clean SIGTERM forwarding.
- Provisioning thresholds — cumulative create/update/delete counters; when a threshold is exceeded the agent refuses further operations of that type without crashing itself.
Further reading: