How the control plane works
Every action — whether triggered by a user, an API call, a workflow, or an AI agent — follows the same path through authorization, execution, and proof. This page traces that path end to end, linking to dedicated deep-dives where they exist.
Intent-oriented commands
Agents say what they want. The platform handles how.
Most platforms give agents a raw API and hope the model figures out the rest. EmpowerNow's Contract-Driven Autonomy (CDA) engine does the opposite: it makes the tools smart so the agents can stay simple. An agent says what it wants — "assign this SAP role" — and the platform handles how: which connector, which authorization policy, which credentials, which proof format. The agent names the intent. The command handles everything else.
The result: agents produce accurate, predictable, reproducible outcomes — and end users feel like the agents are smarter. A user clicks a button, an AI agent calls an MCP tool, a workflow fires on a schedule, SAP GRC fires an approval — they all produce the same typed command, follow the same pipeline, and get the same proof receipt.
Fewer errors, faster execution
Each command carries its own schema, delegation context, identity chain, and authorization requirements. The agent doesn't need to reason about permissions, credentials, or fulfillment order — the tool already knows. Less complexity in the agent means fewer errors and consistent results.
One command, one path
An agent says "assign-sap-role" and the platform's OperationRef — a semantic identifier published in the tool registry — resolves to the correct connector, target system, fulfillment strategy, and authorization policy. No multi-step reasoning. No guessing which API to call. Intent maps directly to execution.
Same result every time
Same command, same pipeline, same proof — regardless of whether a human or an agent triggered it. Results are reproducible because the execution path is deterministic, not emergent. Run the same command tomorrow and you get the same behavior, the same authorization check, the same receipt.
Technical deep-dive CDA engine internals: OperationRef resolution, command lifecycle, and proof generation
OperationRef Resolution
When a request arrives, the CDA engine resolves it to a typed command using the OperationRef — a stable, semantic identifier (e.g., op:assign-sap-role) that maps to the correct connector, target system, and fulfillment strategy. OperationRefs are decoupled from implementation-level ToolIds (tool:sap-abap-role-assign-v2), so refactoring connectors never breaks authorization policies. OperationRefs are published in the registry and discoverable by any agent runtime.
Pre-Execution Authorization
Before any command executes, it passes through the AuthZEN PDP (Policy Decision Point). The PDP evaluates: Who is the subject? What is the action? What is the resource? What constraints apply? High-risk commands trigger the WAITING protocol — the command is suspended until a human approver explicitly approves or denies.
Execution & Fulfillment
Authorized commands are dispatched to the appropriate connector. Each connector exposes a standardized set of operations (Create, Read, Update, Delete, plus custom actions) against its target system. The connector handles protocol translation — RFC for SAP ABAP, SCIM for IAS, REST for BTP — while the CDA engine handles orchestration, retry, and compensation.
Proof Generation
Every command produces a JWS-signed receipt containing: the original request, the PDP decision (including policy version), the execution result, and an evidence fingerprint (AEE — Action Execution Evidence). Receipts are hash-chained — each receipt references the previous receipt's hash, creating a tamper-evident audit trail.
Gate → Decide → Enforce → Prove
This is what the platform page calls "the four-stage path." Here's what happens inside each stage.
Four stages. Every action. No exceptions.
The gateway validates before anything executes
Three checks at the MCP Gateway: Is this the tool the agent was authorized to call? (schema pin verification) Who authorized this agent to act? (delegation chain validation) Is the subject who they claim to be? (identity binding) Requests that fail any check are rejected before reaching the policy engine.
The policy engine decides in real time
The AuthZEN PDP (Policy Decision Point) checks the user's roles, groups, and entitlements in real time. Three possible outcomes: Allow (with constraints), Deny (with a reason code), or Escalate (pause and require human approval via the WAITING protocol). High-risk operations always escalate — never auto-approved.
Five safety rails — all must pass
Before any action reaches a target system, it passes through five independent checks: tool authorization (schema pin), delegation scope (does this agent have permission for this action?), policy decision (PDP verdict), constraint enforcement (budget caps, time limits, rate limits), and identity chaining (the action executes as the real user, not a service account). All five rails must pass. Any single failure stops execution. Fail-closed, always.
Verifiable proof — not just a log entry
Every action produces a cryptographically signed receipt (JWS) capturing what was requested, who authorized it, what was executed, and the result — with an evidence fingerprint for independent verification. Receipts are hash-chained to each other, so tampering with any single record breaks the chain. Auditors verify independently — no trust required in the platform itself.
OAuth Vault & credential isolation
When a workflow or agent needs a user's OAuth token to act on their behalf, the token never leaves the server. Applications request actions, not credentials. The vault fetches the token, uses it, and discards it — the caller receives only the result.
Three-zone trust model (untrusted browser → authenticated BFF → high-security Orchestration Service), nine architectural guarantees, AES-256-GCM encrypted storage with per-tenant key isolation, and automatic refresh.
Read the full OAuth Vault deep-dive →WAITING protocol & approval governance
Patent pendingAgents stop. Humans decide. No exceptions.
When an AI agent is about to do something irreversible — promote an SAP role, modify a production entitlement, provision access across systems — the platform stops. Not with a timeout. Not with a retry loop. The command is suspended, architecturally, until a human decides. The CDA engine returns a WAITING contract: a machine-readable response that tells the caller exactly what the next API call should be once approval is granted.
No workarounds. No timeouts that silently approve. No agent can bypass the pause by retrying or switching tools. The suspension is enforced by the platform, not requested by the agent — which means it works even when the agent is compromised or misconfigured.
No stale approvals
If the situation changes while you're reviewing — someone modifies the workflow, another approver acts first — your approval attempt fails with an explicit conflict, not a silent overwrite. State versioning with HTTP conditional requests (ETag / If-Match) makes this automatic. The platform never lets you approve something that's already moved on.
Exactly-once execution
An approved action runs once and only once — even if the network drops, the user double-clicks, or a replay attack is attempted. The engine issues a single-use execution token paired with an idempotency key. If something goes wrong, retry safely. The platform guarantees the action won't execute twice.
No execution without a decision
Every write operation to an external system must have an authorization decision on record before it executes. No decision, no action — full stop. The governance gate doesn't make approval decisions (the policy engine does). It enforces that one was made. See Fulfillment →
Technical deep-dive WAITING protocol internals: Structured Safety Case, idempotency, and governance modes
The WAITING Response
When a workflow requires human input, it returns: status: "WAITING", a state_version (integer), a fingerprint (SHA-256 of current state), and an mcp_request_format block that tells the caller exactly how to resume — including the run_id, state_version, and idempotency_key. The agent doesn't need to guess how to resume. The contract tells it.
Structured Safety Case (SSC)
The SSC bounds what agents present to human reviewers: summaries capped at 500 characters, reasoning limited to 10 items, evidence limited to 20 items with SHA-256 digests. This isn't a soft guideline — it's a schema constraint. The agent provides bounded, structured context; the human makes the decision with full visibility into the underlying data.
Idempotency
Every approval submission includes an Idempotency-Key header (per IETF draft). The engine guarantees exactly-once execution on retry. Network hiccup? Retry safely. Double-click? Second submission is a no-op. This works in concert with the single-use execution token — the idempotency key prevents duplicate submissions, the execution token prevents duplicate fulfillment.
Governance Modes
Each command type declares a governance mode: fulfillment_required (write blocked unless a valid authorization directive and fulfillment job exist) or none (exempted for internal operations or migration). The safe default is fulfillment_required. If a command doesn't declare a mode, it gets the strictest one.
Approval Types (PDP Decides)
Auto-approved by policy (birthright access, low-risk — instant). Auto-approved with conditions (allowed but requires justification or SoD check — instant). Manager or reviewer approval (high-risk, privileged roles — minutes to days). Multi-level approval (compliance-sensitive changes — hours to days). The governance gate doesn't decide which type applies. The PDP does. The gate enforces that the decision was made before execution begins.
Connector & tool factory
Point at a target system and the factory generates a governed connector — exposed as MCP tools that any agent can call — with no custom code to write or maintain. Each connector gets a standardized operation surface (Create, Read, Update, Delete, plus custom actions), built-in authorization, credential isolation, and proof generation. 73 systems connected today, 2,000+ publishable MCP tools, and adding a new one doesn't require a developer.
Entitlement ledger
Know why every piece of access exists — and revoke safely when it shouldn't.
Most systems track what access a user has. The entitlement ledger tracks why — which request, which rule, which admin override, and how many independent sources assert each grant. When a user has an SAP role granted by both an access request and a dependency rule, the ledger knows both sources. Revoke one and the role stays, because the other source still justifies it.
This is what makes safe revocation possible. Remove a source and the ledger recalculates automatically — no orphaned access, no accidental over-revocation, no "we removed it and now SAP is broken." Every grant can be traced back through its full derivation graph to the specific reasons it exists.
Know why access exists
Each grant tracks how many sources assert it. Six source types: dependency rule, access request, admin override, recertification, migration import, legacy assertion. A compound primary key ensures each source is counted exactly once.
Revoke safely, never break things
Reference-counted grants track how many sources assert each piece of access. Remove one source: if others still justify the grant, the access stays. If no sources remain, the grant is removed. One atomic transaction. No orphaned access. No accidental over-revocation.
Explain every decision
Every grant can be traced back through its full derivation graph — which rules fired, which sources contributed, at what depth. Not "this user has this role." Instead: "this user has this role because of these three specific reasons."
Technical deep-dive Entitlement ledger internals: data model, lifecycle, and dependency resolution
Data Model
17 tables in 8 functional groups. The core tables: entitlement (unified privilege catalog), entitlement_grant (maps identities to entitlements with aggregate reference_count), grant_source (tracks provenance of each individual assertion), and dependency_rule (Basis and Role Profile trigger logic). The compound primary key on grant_source (identity_id + entitlement_key + source_type + source_id) prevents reference count inflation.
Dependency Resolution
Basis rules (triggered by system inventory changes) and Role Profile rules (triggered by entitlement changes) automatically derive dependent grants. All resolution runs locally within the Ledger's own process and PostgreSQL transaction boundary — millisecond latency, no Kafka feedback loops, no distributed coordination. Multi-level cascades converge locally.
Account Lifecycle & Hysteresis
When access is revoked, the ledger doesn't immediately disable the account. Configurable per system: hold_window_seconds (default 900s), require_observed_confirmation (check actual system state in ClickHouse before executing disable), max_defer_cycles (default 3), max_total_defer_seconds (default 86400s). Lifecycle states: ACTIVE → DISABLE_PENDING → OBSERVED_CHECK → DEFERRED → ESCALATED → DISABLED.
Fulfillment Routing
The ledger decides how each provisioning action gets executed: EMPOWERNOW (full lifecycle), LEGACY_PROXY (bridge to existing tooling), or READ_ONLY_OBSERVED (monitor without acting). This allows incremental migration — start by observing, then take over fulfillment system by system.
Proof chain architecture
Every action produces a cryptographic receipt. Not a log entry — a verifiable, tamper-evident proof that captures what was requested, who authorized it, what was executed, and the result. Auditors verify independently, without trusting the platform.
Event-driven automation
If this happens, do that — with full governance, proof, and exactly-once guarantees.
Think IFTTT for identity and security — but every automated action runs through the same governed pipeline as a manual one. An SAP GRC ticket is approved? Provision the role. A new hire appears in HR? Create accounts across six systems. A security violation is detected? Trigger an AI agent investigation. The event automation engine (internally called UEAS) watches for events from SAP GRC, ServiceNow, identity providers, and internal services, then fires governed actions through simple, declarative JSON rules. No code required to add a new automation — just a new rule.
The difference from a regular automation engine: every action triggered by an event passes through the full command pipeline — authorization, credential isolation, five safety rails, and a cryptographic proof receipt. The same governance that protects a human clicking a button protects an event firing at 3 AM.
Catch the event
from any source
Convert to a
standard format
Match rules →
filter duplicates
Queue the action
for execution
Execute once →
never duplicate
Configure, don't code
Need a new automation? Add a declarative JSON rule — not a code deployment. Rules match on event type and attributes, then trigger actions: provision access, start a workflow, launch a playbook, create a human review task, call a connector, or wake an AI agent for investigation. An admin can wire up a new "if this, then that" in minutes.
Every event processed exactly once
No dropped events. No duplicates. Four layers guarantee it: deduplication at ingestion, replay guards, a transactional outbox that commits all writes atomically, and offset tracking that only advances after the database confirms. If something fails mid-flight, it retries safely — never skips, never doubles.
Smart throttling
Five related events fire for the same person in 10 seconds? The system acts on the latest state, not on each event individually. The suppression engine tracks per-subject state and prevents duplicate automations — the same rule won't fire twice for the same person within the configured window. Noisy source systems don't create noisy results.
Technical deep-dive Event automation internals: UEAS event envelope, intent types, and error handling
Normalized Event Envelope (NormalizedEvent)
Every event from every source — SAP GRC, ServiceNow, identity providers, internal services — is normalized into a standard envelope: event_id, event_type, source, source_instance, subject_key, occurred_at, received_at, correlation_id, dedupe_key, and an attrs map of key-value pairs. The normalizer handles source-specific quirks; the rule engine sees only the standard envelope.
What can a rule trigger? (Intent Types)
Seven intent types: create_directive_v3 (provision or deprovision access), start_workflow (graph-based process with approvals and branching), start_playbook (frozen, fully-automated execution plan — no human interaction), create_task (human review: access review, SoD review), execute_action (direct connector action), trigger_sentinel (wake an AI agent for investigation), and start_workflow with parameters. Each intent carries a SHA-256 idempotency key derived from rule_id + event_id + subject_key.
Subject Profiles
Events are categorized by subject profile: ERP_REQUEST (SAP GRC events, keyed by request ID), IDENTITY_LIFECYCLE (JML events, keyed by identity ARN), IFTTT (business events), or CUSTOM. The profile affects windowing, suppression behavior, and correlation state tracking.
Error Handling & DLQ
Transient failures: republish to automation.intents.retry with exponential backoff. Permanent failures or max retries exhausted: publish to automation.dlq. Dead letter queue entries include the full event context, intent, error details, and retry history — nothing is silently dropped.
Performance
Event ingestion: <100ms. Rule evaluation (hot path): <50ms. Throughput: 10,000+ events/hour with a standard Kafka cluster. Template variables use Jinja2-style substitution for dynamic intent configuration.
See the architecture in action.
30-minute technical deep dive. We'll walk through the CDA pipeline, show a live connector operation, and demonstrate the proof chain end-to-end.