DocsGPT signs people in through your identity provider with OIDC SSO, provisions them with SCIM 2.0, and controls access with roles, teams and sharing. Admins see every sign-in and change in one audit log they can export, cap spend with usage quotas, and trace every run into the monitoring they already use.
oidc sso · scim 2.0 · roles · audit log · quotas · traces
Last updated: · Facts checked on
Sign in through your identity provider, and let your directory add and remove people.
DocsGPT signs people in through your identity provider over OpenID Connect, with documented setups for Microsoft Entra ID, Okta, Keycloak and Authentik, and works with any OIDC provider that publishes a discovery document.
Group allowlists decide who may sign in and admin groups decide who administers; both are re-checked at every session renewal, so removing someone from a group cuts their access promptly. SCIM 2.0 creates, deactivates and reactivates accounts from your directory, and back-channel logout ends sessions when your IdP says so.
oidc · pkce · group allowlist · admin groups · scim 2.0 · back-channel logout
| Protocol | Support | |
|---|---|---|
| Microsoft Entra ID | OIDC | Documented setup |
| Okta | OIDC · SCIM | Works with the default web-app configuration; SCIM connector documented |
| Keycloak | OIDC | Documented setup, group mapping, back-channel logout |
| Authentik | OIDC · SCIM | Reference setup in the docs, including SCIM |
| Any OIDC provider | OIDC | Any provider with a discovery document |
Assign the app in your directory
SCIM creates the account before the first sign-in, so nobody has to be set up by hand.
People sign in with SSO
Group allowlists decide who may sign in and admin groups decide who administers, re-checked at every session renewal.
Leavers lose access at once
Deactivating someone in your directory revokes their sessions immediately; reactivating restores access.
Roles are enforced on the server on every request, never trusted from the browser. An instance admin runs the console; inside a team, team admins manage membership and members use what is shared with them. Teams are self-serve.
The first admin is granted from the command line or from an IdP group, and the console refuses to remove the last one.
admin · user · team admin · team member
| Scope | Can | |
|---|---|---|
| User | Instance | Use DocsGPT and own their agents, knowledge, prompts and tools |
| Admin | Instance | Everything a user can, plus users, admins, usage, quotas, the audit log, connectors, defaults and guardrails |
| Team admin | Team | Manage the team's members and settings; not an instance admin |
| Team member | Team | Use what is shared with the team |
Sharing
Share agents, knowledge, prompts and tools with a team or one person. Viewers use them; editors change them. Owners decide whether editors may share or delete, and whether viewers can see an agent's logs.
viewer · editor · editors can share · viewers can see logs
Shared agents
An agent shows what it uses and whose access each item runs with. When an editor adds a tool or source, it runs with their access, and the agent says when someone's access lapses.
what this agent uses · run with my access
Admin console
See every account with its email, activate or deactivate it, grant admins, force a logout that also revokes the person's access tokens, and decide which connectors members may use.
users · emails · admins · access tokens · connectors
Policy
Admin › Guardrails sets the rules every agent follows, existing agents included, and can warn on MCP tools whose descriptions look like prompt injection. Admin › Defaults sets the guardrails every new agent starts with and the settings every new source starts with. See guardrails.
admin › guardrails · admin › defaults
Every sign-in, change and guardrail decision in one append-only timeline.
Admin › Audit log brings sign-ins and denials, provisioning, role and account changes, access tokens, quota and connector-policy changes, data changes, remote-device commands and guardrail decisions into one timeline. Every row records who acted and who was affected.
Filter by category, event, person or time window, search inside the details, and export exactly what you filtered as CSV or NDJSON for your SIEM or an access review. Per-agent Guardrail activity and conversation logs with feedback sit alongside it.
Audit log
See who spends what, and cap it before the invoice does.
Admin › Usage shows spend and tokens over time, latency at the median and the 95th percentile, prompt-cache hits and the top users, split by model, agent or flow.
Usage quotas cap tokens, spend or both per user per day, week or month. Set an instance default, give a team a per-member allowance, and override it for one person; a request over the limit is refused. People with a quota see their own usage and when it resets under Settings › Analytics.
spend · tokens · p50 / p95 · by model, agent or flow · quotas
Every run leaves a trace you can open, or send to the tools you already use.
Logs keep every chat, workflow, schedule, webhook, search and graph build. Open a trace to see each step as a waterfall: retrieval, embeddings and searches, LLM calls with their tokens, tools, guardrails and workflow steps, each with its timing.
Traces keep short previews with secret-named fields redacted, never the full prompt, and are deleted after 30 days. They export as OpenTelemetry GenAI spans to Langfuse, Arize Phoenix, Datadog LLM Observability or Grafana, and the service's own traces, metrics and logs go to any OpenTelemetry backend you run. Nothing leaves until you point it at a collector, and prompt and tool content stays out of the spans unless you opt in.
execution trace · redacted previews · 30 days · otel genai spans · langfuse · phoenix · datadog · grafana
Credentials
Connector and tool credentials are encrypted on the server, the key can be rotated, and shared tools run without exposing them. Access tokens are shown once and stored as a hash, carry a dgpt_pat_ prefix that secret scanners catch, and cannot mint new tokens.
encrypted · key rotation · hashed tokens · dgpt_pat_
Threat model
The threat model is published in the repository next to the code.
THREAT_MODEL.md
Supply chain
A software bill of materials is available for every release; dependencies are watched by Dependabot.
SBOM · Dependabot
CI
CodeQL, Bandit and zizmor run in CI; secret scanning guards the repository.
CodeQL · Bandit · zizmor
Disclosure
Private vulnerability reporting per SECURITY.md, with published advisories.
SECURITY.md
Hardening
A step-by-step checklist for going live: who can reach it, sign-in, secrets, HTTPS, outbound access and the audit trail.
security checklist
The full programme, the disclosure process and certification status are on Security.
Identity stays with your IdP; DocsGPT never stores passwords for SSO users. Roles, teams, the audit log, usage and traces live in your own database, and telemetry goes only to the collector you configure, never to Arc53. On on-premises and air-gapped deployments the IdP is inside your network too; on Cloud, Arc53 operates the database.
SSO, SCIM, teams, sharing, the audit log and quotas are part of the platform in every deployment posture, self-hosted community builds included. See pricing for what else differs.
A specialist consultancy on a dedicated instance with SSO.
Before moving 5,000+ documents onto a dedicated managed instance, a specialist consultancy asked three things: who can sign in, who administers, and what it costs per month.
The same platform and the same settings, operated by Arc53 on a single-tenant server.
5,000+ documents · flat monthly fee
Dedicated managed instance for a specialist consultancy: 5,000+ documents, SSO, one flat monthly fee with no per-seat licence.
Source: No Deviation
A 30-minute demo of SSO, SCIM, the audit log and quotas, or a free on-premises review of your identity setup with an engineer.
Can we use analytics cookies? They show us which pages lead people to sign up, and connect this visit to your DocsGPT account if you create one. If you say no, we still count page views, but store nothing on your device. Privacy Policy