Permission before action.
Review how Durin checks identity, permissions, and approvals for requests routed through its MCP gateway, then records the decision and execution outcome.
Follow the action.
- Requested action
- Create a ticket
- Policy decision
- Approval required
- Reviewer
- Independent approver
- Execution
- Recorded separately
A decision is not proof of completion.
A login is only the beginning.
Durin’s governed request path is built around identity, policy, approval, and audit controls. Provider permissions still apply, and production deployments verify the customer-specific path.
Check who is asking
Requests carry a person or service identity, organization, environment, and connection. Current membership and authority are checked again before execution. WorkOS-backed authentication is implemented, but SSO and MFA enforcement require account-specific verification. A client name alone does not grant access.
Start with access denied
A routed request must satisfy the reviewed tool, resource, connection, and policy requirements. Unknown tools, unsupported resources, and missing permissions stay denied. Production writes are denied by the current policy.
Approve a specific action
Sensitive writes can require an independent approver. The grant is bound to the requester, connection, exact arguments, resource, and current versions of the tool and policy. It expires and can be consumed once.
Record decisions and outcomes
Required audit intent is recorded before execution. A policy allowance and a successful write are different facts. If a write may have happened but cannot be confirmed, its outcome stays uncertain rather than being blindly retried. Scoped exports recheck access; checksums do not make records tamper-proof or independently monitored.
Know where the control ends.
Through the Durin gateway
- Current identity, organization, and connection checks.
- Default-deny policy and exact approvals where required.
- Audit intent and a recorded execution outcome.
Requires separate controls
- Direct API calls, browser actions, shell commands, and clients that bypass Durin.
- Upstream permissions and how an external model provider handles returned data.
- Customer network restrictions and deployment-specific coverage tests.
Understand the data path.
Credentials, audit records, and model-provider data each have a different role. Review them separately.
- Connection credentials
Scoped implementation
Connection configuration uses application encryption and scoped execution checks. Credential refresh, revocation, customer-managed keys, and recovery are handled as provider and customer-specific controls.
- Audit records
Required governance metadata
The default posture records governance metadata, not a full transcript of prompts and tool results. Retention schedules, deletion, legal hold, and restore are handled through customer-specific operating controls.
- Models and operators
Explicit data boundaries
Durin does not host or train AI models. A client can send returned tool results to its model provider. Dedicated tenant resources do not make the SaaS operator cryptographically unable to access data.
Inspect the controls behind a request.
Create an account to evaluate default-allow authorization checks, optional review controls, scoped access, and attributable outcomes.
Create an accountProduction connections use provider setup and trust review.