// Security

Security

Driftless is an agentic product delivery platform. This page describes the security controls Driftless provides — what they protect and what they guarantee — so a security review team can assess our posture without a separate questionnaire. It documents what controls exist, not how they are implemented internally.

Access control

Driftless uses scope-based authorization. Every API key and agent is granted a set of capabilities that determine which actions it may perform and whose data it may reach. Authorization is enforced server-side on every request — permissions are never trusted from the client. A request that exceeds the caller’s granted capabilities, or that targets data outside the caller’s scope, is rejected before any work is done.

Capability tiers

Capabilities are organized into three tiers. An agent or key is granted the minimum tier required for its job (least privilege).

Read	View projects, initiatives, tasks, comments, and media within the granted scope.
Write	Create and update tasks, post comments, and advance task status within the granted scope.
Admin	Manage members, agent credentials and API keys, and organization-level settings.

Assignment and enforcement

Granted by administrators. Capabilities are assigned to agents and API keys by organization administrators from within the Driftless app. An agent or key never holds more capability than was explicitly granted to it.
Checked on every request. Each authenticated request is evaluated against the caller’s capabilities and the organization that owns the target resource. Requests for resources outside the granted scope are denied.
Revocable and rotatable. Credentials can be rotated or revoked at any time; revoked keys stop working immediately, without a waiting period.
Per-agent narrowing. An integration can be scoped so it only has the access it needs — for example, an agent that only moves tasks forward does not also gain the ability to manage members.

Audit trails

Driftless records an audit trail of meaningful actions so organizations can review who did what, and when.

What is logged. Key actions are captured with the acting identity, a timestamp, and the affected target — including task status transitions, comments, agent activity, and administrative changes such as member or credential changes.
Who can view it. Organization administrators can review activity for their own organization. Audit data is scoped to the organization: an administrator of one organization cannot inspect another organization’s activity.
Retention. Activity is retained for a defined period that supports operational review and compliance needs, after which it ages out according to the retention policy.

Audit records describe what happened and who did it. Internal log formats and storage details are not published here.

Human-in-the-loop

Driftless agents work autonomously, but human approval gates the transitions that matter most. Agents cannot self-certify completion or push changes to production on their own.

Task completion. An agent advances work through shaped stages — from in-progress, to blocked when it needs input, to user-testing. A task is only marked done after a human confirms it in their environment. Agents do not mark their own work complete.
Production releases. Deployments to production are initiated by a human operator, not triggered automatically by an agent. A release must pass quality gates before it goes live.
Spec enforcement. Spec gates surface contradictions and require human-shaped acceptance criteria before work proceeds, so an agent cannot ship against an unresolved or contradictory spec.

See human oversight in the AI development lifecycle for how direction, spec gates, and verification fit together in the Cascades operating cycle.

Execution surface

When Driftless ships code for you, the builder agent works in your environment, on your copy of the repository. This section states exactly what that agent can reach: what it can read, what it can write, what it can run, where your code lives while it works, and how your CI is triggered.

What the builder agent can read, write, and run

Read	The assigned task, its acceptance criteria, and the project context Driftless holds for it, reached through the agent’s scoped API key. Locally, the working copy of the repository you designated for that agent. Nothing else on your machine is in scope.
Write	Code changes on a feature branch inside that working copy, pushed with your own git credentials, plus task updates such as comments, status changes, and verification evidence posted back to the Driftless board.
Run	Build, test, and lint commands inside that working copy, as a local process on your machine. The agent runs with the access your machine gives it and nothing more, and it cannot reach the network unless you allow it.

Where your repository lives

The checkout is yours. The builder agent works in the local copy of your repository, at the folder path you configure in the agent’s project settings. Driftless hosts no compute for coding work: your code stays on your machine, the agent reaches it only through the Driftless Orchestrator you run, and Driftless holds none of it.

How CI is invoked

The agent triggers your CI the same way a developer does: it pushes a feature branch and opens a pull request. Your existing pipeline runs on that pull request, under the review and merge protections you already have in place. The agent watches the checks, fixes what fails, and the pull request merges only when your gates pass. The agent cannot bypass your review requirements, and production deployments stay in human hands.

The named systems the agent writes to

Code hosts	Any Git remote your checkout is configured with. The agent pushes feature branches using your own git credentials, so it works with whatever host your repository already uses — GitHub, GitLab, Bitbucket, or a self-run Git server. Driftless hosts no copy of your code.
CI systems	Whatever pipeline already runs on your pull requests. The agent triggers CI the same way a developer does — push a branch, open a pull request — and watches the resulting checks. No CI-specific integration is required on either side.
Test results back to tasks	Check results and verification evidence are posted back to the Driftless task as comments, evidence entries, and status updates, so the trail from a failing check to the fix lives on the task record.
Shell and tool permissions	The read, write, and run tiers in the table above: scoped API access through the agent’s key, writes limited to the designated checkout on a feature branch, and local command execution inside that checkout only.
MCP surface	A live MCP endpoint over JSON-RPC 2.0, documented at /docs/mcp, plus the REST API documented at /docs/api.

In short: a scoped Driftless API key plus your own local git credentials, one designated checkout, and pull requests you can see and control. The full local execution model is described in Engineering & Architecture.

Execution sandbox

Agents that execute code run inside a sandbox: a deliberately narrowed execution environment that defines what the agent can touch, and nothing more. Driftless runs agents in two sandboxed contexts. Hosted agents (the business-analyst agent) run in Driftless’s multi-tenant server. Coding agents (the orchestrator’s builder agent) run on your machine, inside the checkout you designated for them. This section describes the three things that define each sandbox: how it is isolated, what resources it may consume, and which security controls govern it.

Isolation mechanisms

Hosted agents are tenant-isolated. The business-analyst agent runs in Driftless’s multi-tenant web server, with concurrent work isolated at the process and request level. Each agent is scoped, tool-limited, and tenant-isolated: it can only act within the organization it was authenticated for, and only with the tools it was granted.
Coding agents are network-isolated. The builder agent runs as a local process on your machine, sandboxed from the network: it cannot reach the internet unless you allow it. It sees one designated working copy of your repository and nothing else on your machine.
Concurrent coding agents do not share a working tree. Each dispatched agent works in its own git worktree of your repository checkout, so two agents never edit the same files in the same working copy at once.
Dispatch is intent-checked. Before an agent is dispatched, the files it intends to touch are recorded in an intent registry and checked for overlap with the intents of agents already working. Overlapping intents are caught before dispatch, not discovered as merge conflicts after the fact.
Credentials stay inside their lane. A hosted agent holds a scoped Driftless API key bound to one organization. A coding agent holds your own local git credentials plus a scoped API key, and Driftless hosts no compute for coding work, so no agent execution happens on infrastructure you do not control or own.

Resource limits

API-level limits. Agent traffic is subject to the same per-key rate limiting as every other caller of the Driftless API: 100 requests per minute per API key, together with platform abuse protection.
Bounded autonomous work. An agent’s retry budget is finite. Transient failures are retried at most three times with exponential backoff; after that the work stops and escalates to a human blocker. Agents cannot loop indefinitely on their own.
Compute is owned, not borrowed. Coding agents consume your machine’s resources, under the limits your machine imposes. Driftless supplies no compute for coding work, so no unseen resource pool is ever spent on your behalf.

Security controls

Least privilege by default. An agent is granted the minimum capability tier its job requires. Scope-based authorization is enforced server-side on every request, and credentials can be rotated or revoked at any time, taking effect immediately.
Human approval gates. Agents cannot self-certify completion or push changes to production on their own. Work advances to user-testing, and a person decides what merges and what deploys.
Auditable activity. Every task transition, comment, and credential change lands in your organization’s audit trail, so automated work stays attributable to the agent identity that performed it.

Secrets isolation

Scoped capability tiers. Every agent and API key holds the minimum capability tier its job requires — read, write, or admin — enforced server-side on every request. An agent never inherits more reach than was explicitly granted to it.
Rotation and instant revocation. Driftless API keys can be rotated at any time, and revoked keys stop working immediately, without a waiting period.
Provider keys stay in the vault. BYOK provider keys are encrypted at rest with AES-256-GCM in a per-user vault, proxied server-side, masked in every interface, and never exposed to the browser. Every credential action is audited. The full key-handling model is published on the BYOK and key sovereignty page.

The sandbox is a boundary the agent cannot redraw: scope defines what it may reach, rate limits and retry budgets bound how much it may do, and human approval gates what ships. The full execution model is described in Engineering & Architecture.

Data isolation

Driftless is multi-tenant. Each organization’s data — projects, initiatives, tasks, comments, media, and agent activity — is logically isolated from every other organization.

Request-scoped access. Every authenticated request is bound to the caller’s organization. Authorization checks ensure a request can only read or modify resources that belong to that organization.
No cross-organization leakage. An agent or API key authenticated for one organization cannot enumerate, read, or modify another organization’s data. Cross-organization access is rejected, not merely hidden.
Agent identity, not user impersonation. Agent and API-key actions are attributed to the agent identity and scoped to its organization, keeping automated activity separate and accountable.

Encryption

Driftless protects data both in motion and at rest.

In transit	All traffic to Driftless is encrypted with TLS (HTTPS). Plain-text HTTP is not accepted for application or API traffic.
At rest	Stored data — including task content, comments, media, and configuration — is encrypted at rest in the underlying storage layer.
Key management	Encryption keys are managed through the hosting platform’s key-management capabilities and rotated per platform policy.

This section describes encryption capabilities. Internal key-management implementation is not documented on this page.

Reliability

Driftless commits to keeping the hosted Service available. This section describes the architecture the Service runs on, how availability is monitored, and how incidents are handled. The full commitment is published in the Service Level Agreement.

Architecture

The hosted Service consists of the Driftless application at app.godriftless.ai, the REST API, and the MCP endpoint, served over HTTPS from managed cloud infrastructure. The marketing site is hosted separately as static files behind a content delivery network, so it does not share a failure domain with the application.

Monitoring

The Service’s public health endpoints are polled externally by Better Stack at 30-second intervals, around the clock. Monitoring results are published live on the public status page together with incident history and maintenance notices, so availability claims are verifiable against live evidence rather than taken on faith. Measured uptime has been 100% since monitoring went live in June 2026, and the published SLA commits to a 99.5% monthly uptime target.

Incident response

When an incident affects availability, we update the status page as the situation evolves, notify affected customers by email and through the status page, and publish a resolution summary with root cause and corrective actions after the incident is resolved. Response targets by severity are defined in the SLA.

This section describes the reliability posture at the level of what the Service runs on and how availability is watched. Internal topology and tooling beyond the public status page are not documented here.

Responsible disclosure

Driftless welcomes responsible disclosure of security vulnerabilities from researchers and customers. If you believe you have found a vulnerability, please report it privately so we can investigate and remediate.

Security contact

Report vulnerabilities to security@godriftless.ai. Encrypted email is preferred; a PGP key is available on request. Please do not report security issues through public channels.

Response timeline

Acknowledge	Within 48 hours of a valid report.
Initial assessment	Within 5 business days, including severity and a proposed remediation plan.
Remediation	Target within 90 days, depending on severity and complexity. We coordinate disclosure timing with the reporter.

Scope

In scope: the godriftless.ai marketing site and the app.godriftless.ai application, including its REST API and MCP endpoint.
Out of scope: third-party services or infrastructure not operated by Driftless, and issues that require violating the application’s terms of use.

Safe harbor

Good-faith research that respects user privacy, does not access or modify others’ data, and does not degrade service availability will not result in legal action against the reporter. We ask that you give us reasonable time to remediate before any public disclosure.