The Owlie platform
Identity governance,
from source to enforcement.
Connect systems, establish identity and access state, make governance decisions, and carry those decisions all the way through fulfillment.
Platform architecture
Five engines. One connected state model.
The engines are not five separate feature areas. Each reads a specific layer of platform state, records its decision or result, and hands the work to the next responsible system.
- Admin console
- End-user portal
- Slack
- AI assistant
- API · SDK · MCP
Sync engine
Systems → observed state
- What it works from
- Connector observations, source checkpoints, and prior graph state.
- What it establishes
- Accounts, groups, resources, Grants, relationships, and their observed state.
- What it hands off
- Drift handling and downstream evaluation when source state changes.
Policy engine
State → desired access
- What it works from
- Identity attributes, group membership, and the policies written against them.
- What it establishes
- The desired Grant set, and the rule that produced each grant.
- What it hands off
- Provisioning whenever desired state diverges from observed state.
Request engine
Intent → governance decision
- What it works from
- Catalog scope, requester context, and the approval policy that applies.
- What it establishes
- Request records, approval decisions, and the justification behind each grant.
- What it hands off
- Provisioning on approval, and expiry on time-bound access.
Review engine
Existing access → governance decision
- What it works from
- Current holdings, their granting sources, captured risk signals, and campaign scope.
- What it establishes
- Campaign outcomes, certify and revoke decisions, and review evidence.
- What it hands off
- Revocation provisioning for any access that is not certified.
Provisioning engine
Desired state → real-world change
- What it works from
- Desired state, connector capabilities, and target credentials.
- What it establishes
- Operations, results, applied state, and the operation journal.
- What it hands off
- Re-observation and verification after every apply.
Identity Store
One record of access, carried through four states — every engine reads and writes here.
- Observed stateWhat connected systems currently report.
- Decisions & justificationsWhy each access should or should not exist.
- Desired stateThe access outcome the platform has calculated.
- Applied stateWhat fulfillment last completed in the target system.
Transaction trace
See how Owlie handles a change.
A single event can cross several engines. Follow four common changes from first observation or intent through decision, enforcement, and reconciliation.
Illustrative transaction
Alice requests GitHub Admin.
Time-bound access for a production task.
Pan the transaction to follow every step
- RequestCaptures intent, reason, and access window
- PolicyChecks applicable rules and conflicts
- ApprovalRoutes the decision to Alice’s manager
- ProvisioningCalculates the required membership change
- GitHubAdds Alice to the governed team
- ReconciliationConfirms the resulting observed state
Illustrative transaction
A new engineering employee appears in the authoritative HR source.
Baseline access follows the employee’s resolved identity and relationships.
Pan the transaction to follow every step
- HR sourcePublishes the worker record
- HR connectorReads the new source state
- SyncNormalizes the observation
- Identity StoreResolves identity and relationships
- Identity eventsRecords the semantic change
- PolicyCalculates baseline desired access
- ProvisioningPlans account and Grant changes
- ConnectorsApply changes in target systems
- SyncReconciles the resulting observed state
Illustrative transaction
An employee moves from Support to Engineering.
Owlie recalculates access from the changed source context.
Pan the transaction to follow every step
- HR sourceChanges department and manager
- SyncObserves the new attributes
- Identity StoreResolves the updated relationships
- Identity eventsRecords the semantic change
- PolicyRecalculates desired access
- ProvisioningPlans grants and removals
- ConnectorsApply the changes
- SyncConfirms target-system state
- Identity StoreUpdates effective access
Illustrative transaction
A quarterly campaign asks an application owner to recertify privileged access.
A revoke decision travels through the same enforcement path as a grant.
Pan the transaction to follow every step
- ReviewBuilds scope from campaign rules
- Identity StoreSupplies access and granting context
- ReviewerRevokes an unnecessary assignment
- ReviewRecords the decision and evidence
- ProvisioningCalculates the removal
- ConnectorRemoves the target Grant
- SyncObserves the result
- ReviewCloses remediation with evidence
Extension points
Extend the platform at every layer.
Every layer has a configuration path and an extension path. Configure the standard case visually; when the business needs something unusual, the same layer accepts expressions, Functions, or a connector you build — without leaving the platform.
Install from the catalog, or point a protocol rail — SCIM, LDAP, SQL, CSV — at a system that already speaks one.
- Builder
- Function
Define authentication, entities, and relationships in the connector builder, then write one TypeScript Function per sync and provisioning operation. Start from an OpenAPI import or from scratch.
Custom attributes, field mappings, identity-reference mappings such as manager, and a drift policy per resource: adopt, flag, or preserve.
- OXL
- Derived attributes
Expressions that shape incoming values and match external accounts to the right identity. Derived attributes computed from your own rules — lifecycle states included.
Catalog scope, time-bound access windows, and a request Form per resource that captures the context the workflow needs.
- Forms
- Function
Form answers travel into the approval, fulfillment, or action Function that acts on them, so your logic works with what people provide.
Staged approval policies — all, any, or N-of-M — routed to managers, owners, or groups. Review campaigns with reviewer routing on the same terms.
- Function
Approval Functions that approve, reject, or reassign using form answers and external checks. Reviewer-resolver Functions that choose who decides.
A provisioning profile per resource: attribute mappings, before and after hooks, and timed steps for staged deprovisioning.
- Hooks
- Function
- OXL
Fulfillment Functions for systems without a native connector. Hook Functions around any apply. Expression-computed account values, including references to accounts on other resources.
Grant and deny policies over any attribute, group, or role, plus separation-of-duties pairs and revocation routing.
- OXL
- Function
- Custom Actions
Reactions run your Functions on identity, group, or resource events, with expression conditions deciding when they fire. Custom Actions expose your own operations on identities and requests, with optional input forms.
One runtime under every extension. Code you add runs in the same sandbox as everything else on the platform.
- Versioned releases
- Draft, publish, roll back
- Scoped secrets
- Bound to the release that uses them
- Allowlisted egress
- Outbound calls only to declared hosts
- Execution history
- Every run recorded for review
Platform directory
Explore the platform.
Go deeper on the subsystem responsible for the work you need to understand.