Private application access

Boundary and setup

Private access is disabled unless the platform enables it. The service does not open inbound customer-network connections, and the repository does not ship an agent. A customer agent polls outbound over signed mutual TLS; this control channel is not a general proxy. Tenant managers register an exact HTTPS endpoint. Independent God approval is required before delivery.

1. Confirm feature, tenant application, profile and enrolled agent state.
2. Enter exact HTTPS destination and permitted paths; do not submit credentials.
3. Submit for approval and wait for approved state before expecting delivery.

Agents, certificates and devices

Agent enrollment uses one-time bootstrap, customer-held private key, short-lived certificate and signed requests. The key is never uploaded. Rotation and revocation are separate; revocation rejects all agent certificates. Managed-device posture is an assurance signal, not proof of health. Check evidence freshness before policy use.

1. Create enrollment for the intended tenant connector; protect its one-time token.
2. Generate the key locally and confirm enrolled, compatible agent status.
3. Rotate before expiry; revoke compromised agents or stale device certificates.

Network zones and policy

Policies can consider tenant, application, role, resource, device assurance, authentication strength, session age and network signals. Report-only explains prospective decisions but does not block access. Policies are versioned; preview before publishing. Health diagnostics and a network signal alone never grant access.

1. Inspect tenant and app scope, signals, priority and enforcement mode.
2. Preview a representative request and compare its expected decision.
3. After publishing, inspect the real decision; correct scope, not assurance checks.

Assignments, sessions and disconnect

Assignments target a user, group or package and may require approval and expiry. Users disconnect their sessions; tenant managers can terminate sessions for their application. God-only emergency disconnect requires recent phishing-resistant step-up and revokes app sessions, endpoints, vaulted credentials and token families. It does not revoke an agent shared by other apps or clear an upstream cookie.

1. Request the exact app assignment and verify approval before use.
2. Confirm user and app in the inventory before terminating a session.
3. For emergency disconnect, complete genuine step-up and verify revoked state and audit.

Workload identities and secrets

Workload identities have owners, trust, credentials, tokens, package assignments, reviews and incidents. Read and write operations require their respective permissions. Request only required trust or package access and complete ownership or independent approval. Revoke exposed tokens or certificates. Never put secrets in profile data, audit notes or exports.

1. Check identity owner, tenant, credentials and review state.
2. Request the specific trust or package with purpose and required approval.
3. Rotate credentials and revoke exposed tokens or certificates; verify inactive state.

Diagnostics, audit and retention

Diagnostics show bounded events, categorical decisions, latency, agent freshness and certificate expiry; they omit request content, credentials, tokens, raw IPs and user agents. Audit, evidence packs, retention, holds and exports are separate scoped controls. Treat downloaded evidence as sensitive. Management API contract: /api/auth/management/openapi.json.

1. Check tenant and app scope, agent freshness, health and denial category.
2. Use audit or evidence packs for retained investigations; limit the scope.
3. Check permissions and holds before export or retention changes; verify the audit result.

Frequently asked questions

Related pages

• Single sign-on and identity
• Federation protocols and provisioning
• SSO administration
• Identity governance and privileged access