Identity And Access

Use This Doc For

Read The Identity Model

DPF uses one principal spine to connect a person, AI coworker, or service identity to aliases, groups, route access, and governed authority. Upstream directories can supply identity facts, but DPF retains local control over platform roles, route bundles, coworker associations, and tool execution.

Your install is the directory. People, AI coworkers and service accounts are published as one tree that ordinary directory tools can read over a secure connection, so existing software can look up who works here without a separate identity product. The tree is built from the principal spine and is read-only: you change identity in DPF, and the directory follows. Its address is derived from your organization, so it reads as your namespace rather than a generic one.

Serving it is a choice you make. The directory is off until you turn it on, because an install should not start answering an identity protocol just because it was upgraded. Platform → Identity → Directory tells you which of three things is true: it is serving, it is not served, or it was turned on and failed to start — with the reason. Turning it on needs your organization’s own CA, because the connection is secured with your certificate and there is no self-signed fallback. See serving the directory.

Two consequences worth knowing. Disabling a principal now ends its ability to sign in immediately, rather than waiting for a sync — authority and sign-in can no longer drift apart. And people sign in with a password, while AI coworkers and service accounts identify with a certificate from your organization’s own authority: they have no password to steal, guess or leak.

flowchart LR
    source["HR, AI Workforce, or upstream directory"] --> principal["Canonical principal"]
    principal --> alias["Aliases and federation links"]
    principal --> group["Role and team membership"]
    group --> binding["Authority binding"]
    binding --> route["Visible governed routes"]
    binding --> execution["Runtime coworker and tool checks"]
    execution --> audit["Decision and execution evidence"]

    classDef source fill:#dbeafe,stroke:#2563eb,color:#172554
    classDef identity fill:#ecfdf5,stroke:#059669,color:#052e16
    classDef authority fill:#fff7ed,stroke:#ea580c,color:#431407
    class source source
    class principal,alias,group identity
    class binding,route,execution,audit authority

Text alternative: identity facts enter through HR, AI Workforce, or an upstream directory and resolve to one canonical principal. Aliases and group membership connect that principal to authority bindings. Bindings shape route visibility, while runtime checks decide whether a particular coworker or tool action may execute and record the result for audit.

Choose The Right Surface

Surface Use it to answer
Principals Which canonical employee or coworker identity does this record represent, and which aliases point to it?
Groups Which platform role, business group, team membership, or coworker ownership connects this principal to work?
Authorization Which shared binding gives a subject access to a governed resource, with what status and evidence?
Directory What identity and group state can DPF project for directory-compatible consumers?
Federation Which upstream authority is connected, and which facts remain upstream versus locally governed?
Applications Which relying parties or future LDAP/SCIM consumers can inherit published identity and group state?
AI Coworker Identity Which workforce identities have principal coverage and portable identity metadata?

Change Access Deliberately

For an assistant connected through OAuth, sign in and approve its role once. Reconnects, token refreshes and new tasks reuse that connection. Every operation still checks the signed-in person’s current permissions.

If an approved assistant cannot use internal work information, an administrator can open AI Coworker Identity → Data access, select that coworker, and expand Change data access. Choose only the information it needs, record the reason, and save. You cannot assign access above your own. The saved setting applies to that coworker across connections immediately; users do not sign in again. Reducing access takes effect on subsequent requests too.

This setting does not grant tools, waive action approvals, or invite anyone into a workroom. A room owner must separately admit the people and assistants who will work there. Signing in again cannot fix a missing invitation.

Open the selected workroom’s Participants → Assistant access to admit an assistant from your approved connections. Choose Read only or Contribute and save. This changes that room alone; sibling rooms and other users stay separate. Existing connections use the saved access without another sign-in. If the room has a broader case restriction, its owner must resolve that too.

The data-access selector includes older assistant identities still used by connections. Similar names show their identity IDs so an administrator can update the exact assistant without replacing the connection.

  1. Start with the principal you need to explain or change. Resolve duplicate or ambiguous aliases before changing access around them.
  2. Inspect role, group, and team membership. A group change can affect several routes or coworker relationships at once.
  3. Open Authorization and filter by subject, resource, coworker, or status. Treat the authority binding as the shared record of who may access which governed surface.
  4. Open the binding detail and review its evidence before editing. Only users with manage_platform can write or bootstrap bindings.
  5. Validate the downstream effect on route visibility, tool grants, delegated scope, and coworker authority. Use Governance & Audit → Authority for the corresponding audit-first view.
  6. After a directory or federation change, verify both sides: the upstream identity fact and DPF’s local binding. A connected directory is not itself a DPF authorization grant.

Coworker actions are re-evaluated when the tool actually runs. The platform intersects the current employee authority, coworker grant, delegated scope, record scope, connection state, data sensitivity, and oversight policy. A denial is returned as a plain-language explanation; an action that needs judgment pauses the originating task and creates one approval envelope. Approving that envelope does not approve a different task or changed action.

Your OAuth sign-in is itself a recorded decision. When you approve an assistant’s role, routine changes inside those permissions run without a further card: an evidence entry, a verification result, or a backlog item you asked for. You are still asked when a change reaches outside the platform, cannot be undone, changes who may do what, touches restricted data, or is defined as a proposal. A personal access token or an unbound connection does not count as this decision.

Each approval card shows the action, where it lands, the exact proposed content, its consequence, why you are being asked, and what authorizing covers. Authorizing permits that one request. It does not review the content or confirm that any test it cites is correct. If the card cannot load the proposal, it says the effect is unresolved; decline unless you already know what it writes. When you authorize an assistant’s request, the platform runs it once, straight away, with the same checks it would have run for the assistant. The card then says whether it finished. If the assistant sends the same request again, it gets that recorded outcome; the change is never made twice. The same holds when the request came from a task the assistant handed to a coworker: your approval resumes that task, even if the assistant has since restarted. A request is not run if its connection was revoked or narrowed, or if the stored request cannot be proven identical to what you saw. A card answered after its window closed marks the request expired instead.

Recovery And Evidence

What To Watch

Edit this page on GitHub