Security and trust at AgentTask

Architecture and tenancy

AgentTask is a multi-tenant service running on Google Cloud. The product is a small set of container services — the web application, the API, the marketing site, and an internal operator console — in front of one managed PostgreSQL 16 database and a Cloud Storage bucket for attachments.

Tenancy is logical. Every record carries an organization id, and every request is resolved into a single server-side tenant context before any query runs. That layer normalises each credential the platform accepts — a signed-in user’s session, an organization API key, an MCP OAuth token, a claim token issued to a running agent, an internal service token — into one object carrying the organization, the kind of actor, and, where the credential is limited to particular spaces, the spaces it may touch. A credential that should carry a space restriction and arrives without one is denied rather than widened.

• One shared PostgreSQL database, with organization scoping enforced in the application layer.
• One tenant-context resolver for every credential type, covered by tests that fail the build if the permission definitions it reads drift apart.
• The internal operator console is a separate service reachable only through Google Cloud IAP, behind a Google sign-in and a named allow-list — and an operator reading a customer’s data is itself written to the audit trail.

Where the limit is: Isolation is enforced by the application, not by the database. PostgreSQL row-level security policies exist in the schema but are deliberately shipped disabled, and no tenant has its own database, schema, or encryption key. If your requirement is database-enforced or physical separation, AgentTask does not meet it today.

Encryption

Everything in transit is encrypted. All public endpoints are HTTPS. The application reaches the database through the Cloud SQL Auth Proxy, which authenticates with IAM and client certificates over a TLS channel; the instance is configured to refuse unencrypted connections, and no network ranges are allow-listed to connect to it directly.

At rest, the database, the attachment bucket and the database backups are covered by Google Cloud’s default encryption.

Above that, AgentTask encrypts the values that would be most damaging to leak before they ever reach the database. Integration credentials, OAuth tokens, model-provider API keys, webhook secrets and connected-machine secrets are sealed with AES-256-GCM — a fresh random nonce per value and an authentication tag, so a tampered ciphertext fails to decrypt rather than decrypting to something else. The key lives in Google Secret Manager and is injected into the service at runtime; a second decrypt-only key slot allows rotation without downtime.

Account identity fields use the same mechanism: an email address is encrypted, and lookups are performed against a keyed HMAC-SHA-256 of the normalised address.

Where the limit is: Two limits worth stating plainly. Customer-managed encryption keys are not offered — at-rest keys are provider-managed. And the application-layer encryption of identity fields is not yet uniform: some account-creation paths still write the address in clear text alongside the lookup HMAC, and records created before the mechanism existed have not been migrated. Task titles, descriptions, comments, notes and attachment contents are not encrypted above the storage layer.

Hosting, regions and subprocessors

AgentTask is operated by AgentTask LLC and hosted on Google Cloud Platform. Production runs in its own Google Cloud project, in a single region in the United States, entirely separate from the development project.

Development and production share no credentials. The attachment bucket, its access keys, the database and every secret are created per project, so a development service cannot read production data even by mistake. Attachment storage uses uniform bucket-level access with public access prevention enforced, written by a service account whose permissions are scoped to that one bucket; object versioning is on and incomplete uploads are cleaned up automatically.

The parties that process data on our behalf today:

• Google Cloud — hosting, the managed PostgreSQL database, object storage, and the platform-managed AI models used by default.
• Stripe — payment processing for paid plans. Checkout and the billing portal are hosted by Stripe, so card details never reach AgentTask.
• A transactional email provider, for verification, billing and notification mail.
• On Enterprise, if you connect your own model provider, that provider is your subprocessor rather than ours and prompts go to your endpoint instead of the platform-managed model.

Where the limit is: There is one production region. Region selection, EU data residency and per-customer region pinning are not offered. A formal, versioned subprocessor list and a standard data processing addendum are not yet published — the list above is what we can state today, and we will confirm the current version in writing if you ask. One retention disclosure is worth raising before you ask about it: realtime voice, when it ships, will relay audio to the platform-managed Google model with session resumption enabled, which Google documents as retaining cached prompts, audio and model output for up to 24 hours and as incompatible with zero data retention. That specific mechanism applies to voice only — but it is not a claim that other traffic is subject to zero data retention. We have not established a zero-data-retention arrangement with our model provider for any traffic, and prompt logging for abuse monitoring runs at the provider’s default. Ask us and we will put the current position in writing.

Authentication and access control

People sign in with an email address and password, with Google, or with Apple. Passwords are stored as bcrypt hashes. New accounts must confirm their email address before use, and a password sign-in from a device we have not seen before has to be confirmed with a code sent to the account address — which also challenges scripted logins with a stolen password.

A session is an opaque random token in an httpOnly cookie; only a SHA-256 hash of it is stored server-side, so a copy of the database does not yield usable sessions. Sessions expire after seven days, and a signed-in user can review their recent login events and sign out every other session from their settings.

Programmatic access uses organization-scoped API keys, stored as bcrypt hashes and expiring a year after issue. Agents connecting over MCP authenticate with OAuth, and an agent that claims a piece of work receives a token scoped to that work rather than to the whole organization.

Inside an organization, permissions are per member rather than per role tier. Twenty-two permission keys — who may create, edit, delete, assign, administer and so on — are defined once in a shared definition that both the API and the interface read, are defaulted deliberately, and can be overridden per space. A drift test fails the build if the two sides ever disagree.

Where the limit is: SAML and OIDC single sign-on, SCIM directory provisioning and multi-factor authentication are not available. Account roles are still only administrator and member; richer roles, an auditor role and delegated administration are in development. Deactivating a member today refuses their sessions but does not yet revoke every long-lived credential they hold — that gap is being closed, and until it is, revoke API keys explicitly when someone leaves.

How agent execution is bounded

This page exists because AgentTask gives work to agents. Two things bound what an agent can do: the credential it holds, and where it runs.

An agent never holds a person’s session. It authenticates with an organization API key, an MCP OAuth token, or a claim token issued for one piece of work — all resolved through the same tenant-context layer as a human request. A user-scoped agent credential that arrives without its space restriction is denied rather than treated as organization-wide, and the tools exposed over MCP are capped by the permissions of the identity that called them: an agent cannot exceed the person or key that invoked it.

Execution happens on machines you connect rather than on ours. AgentWork and the agent fleet run on hardware you control, using your own repository access, so source code and working files stay in your environment. On Enterprise you can also route model inference to your own provider endpoint with your own key, so prompts and completions leave through a boundary you chose.

Where the limit is: Agent activity is audited at the request level — the calls an agent makes over MCP, an organization key or a connected machine land on the same trail as any other client, and field changes made over MCP are stamped as such. A first-class per-agent action record, an organization-wide agent policy engine, a fleet-wide kill switch and per-model spend caps are in development. Do not assume them today.

Data retention, deletion and export

Your content is retained for as long as your organization is. Attachments live in a versioned bucket, so an overwrite or delete leaves a recoverable previous version; superseded versions move to colder storage after thirty days and are removed after a year.

Audit events are append-only by construction. A database trigger refuses updates and deletes outright, and expiry happens by dropping a whole day’s partition rather than by deleting rows — which is why an entry cannot be quietly edited after the fact. The default retention window, however, is deliberately short: days rather than months, chosen as data minimisation rather than derived from a compliance requirement. That is shorter than the evidence period most audit programmes assume, and lengthening it is an open decision rather than something already done.

Where the limit is: There is no self-service flow to export everything an organization holds or to delete the organization itself. Deletion is performed by us on request, and it does not currently remove attachment objects from storage. An organization-wide export is in development. If you need a contractual export or deletion commitment, raise it with us before you sign rather than assuming the product covers it.

Backup and recovery

The production database is backed up automatically each day, and backups are retained for thirty days. Point-in-time recovery is enabled with a seven-day transaction-log window, so the database can be restored to a chosen moment inside the last week. Deletion protection is enabled on the instance both in our infrastructure definitions and at the cloud provider, so an accidental delete is refused rather than confirmed.

Where the limit is: Production runs a single zonal database instance: there is no hot standby and no automatic cross-zone failover, so a zone outage means downtime recovered from backup. Backups are held in the same region as the data. We do not publish a recovery time or recovery point objective, and we have not carried out a documented restore drill — so treat any RTO or RPO you need as something to agree with us rather than something to read off this page.

Incident response and notification

Production is watched by external uptime checks against the application, the API and the marketing site, with alerts delivered to the operating team. The audit trail — privileged reads and every write — is what an investigation starts from.

If we determine that customer data has been accessed or disclosed without authorisation, our commitment, absent a signed agreement that says otherwise, is to notify the administrators of affected organizations without undue delay, and to tell you what we know, what we do not yet know, and what we are doing about it.

Where the limit is: A formal incident response plan — severity definitions, on-call escalation, a contractual notification deadline, post-incident review — is in development, and there is no committed notification deadline beyond the above. The public status page is updated by hand rather than driven by monitoring, so do not treat it as a live health signal.

Compliance status

AgentTask holds no third-party security certification. There is no SOC 2 report, no ISO 27001 certificate, and no completed independent penetration test. We would rather say that in one sentence than let a row of badges imply otherwise.

A published subprocessor list, a standard data processing addendum and a security whitepaper are being prepared; none is published yet, and this page stands in their place. If you are running a vendor assessment, send us the questionnaire and we will answer it against this page rather than around it.

How changes reach production

Nothing reaches production from a laptop. Both deployment branches are protected and require a reviewed pull request; changes to infrastructure or CI additionally require the code owner’s approval.

A release is identified by an immutable version tag created by CI when the version change is merged — never by a person and never re-cut. That tagged build is deployed to the development environment first and left to soak, and promotion to production is a fast-forward of the very same commit behind a second review. The build that was tested is therefore the build that ships; production is never a fresh rebuild from a different source.

Reporting a vulnerability

We publish a vulnerability disclosure policy with a safe-harbour statement for good-faith research, an explicit scope, and the response targets we hold ourselves to. The same contact details are machine-readable at /.well-known/security.txt. We do not operate a paid bug bounty.