Skip to content

AgentTask for Enterprise

Agent work your security team can actually evaluate

Humans and AI agents on one governed backlog — with the controls written down instead of implied. Below: how identity works, how agents are bounded, where your data lives, and where the gaps are, before you have to ask.

The questions your security team will ask first

Short answers here, full evidence — including every control we do not have — on the trust page.

How does identity work?

Email and password (stored as a bcrypt hash), Google sign-in, or Apple sign-in, with mandatory email confirmation and an emailed code for sign-ins from a device we have not seen. Sessions are opaque tokens kept server-side only as hashes and expire after seven days. Inside an organization, access is per member across twenty-two permission keys with per-space overrides. SAML/OIDC single sign-on, SCIM provisioning and multi-factor authentication are not available today, and account roles are still administrator and member only.

Access control detail

How are agents governed and bounded?

An agent never holds a person’s session. It authenticates with an organization API key, an MCP OAuth token, or a token scoped to the single piece of work it claimed — and the tools it can reach are capped by the permissions of the identity that invoked it. Execution runs on machines you connect, with your own repository access, so source and working files stay in your environment. A per-agent action record, an organization-wide policy engine and a fleet-wide kill switch are in development, not shipped.

Agent execution detail

Where does our data live?

In one Google Cloud project in a single United States region, entirely separate from our development project and sharing no credentials with it. Encrypted in transit and at rest, with integration credentials and provider API keys additionally sealed with AES-256-GCM before they reach the database. Region selection and EU data residency are not offered.

Hosting & subprocessors

What is the security posture?

No SOC 2 report, no ISO 27001 certificate, no completed independent penetration test — we would rather write that sentence than imply otherwise with a row of badges. What we publish instead is the control-by-control state of the platform, including everything marked not available, plus a vulnerability disclosure policy with safe harbour for good-faith research.

Trust page

How do we reach a human?

One monitored inbox. Send your questionnaire, your DPA draft, or the specific control you need confirmed in writing, and you will get an answer written against the trust page rather than around it.

support@agent-task.com

One request

Security & compliance pack

Everything an evaluation needs, from one email. We will tell you plainly what the pack does not yet contain: a published subprocessor list, a standard data processing addendum and a security whitepaper are being prepared and are not available today.

  • Control-by-control posture — including the controls we do not have
  • Architecture, tenancy, encryption, hosting, retention and backup detail
  • Vulnerability disclosure policy and the RFC 9116 security contact
  • A written response to your own questionnaire, answered against the above

The controls that are actually in place

Nine things the platform does today. What it does not do yet is listed just as prominently on the trust page — that list is part of the pitch, not hidden from it.

Per-org isolation

Every record carries an organization id, and every request resolves through one server-side tenant-context layer that fails closed when a scoped credential arrives without its scope.

Append-only audit trail

Writes across the web app, desktop, MCP and organization API keys are recorded by default, and a database trigger refuses updates and deletes outright. Retention is short by default — the trust page says how short.

Bounded agent execution

Agents authenticate with scoped credentials, never a person’s session, and cannot exceed the permissions of the identity that invoked them.

Encrypted secrets

Integration credentials, OAuth tokens and provider API keys are sealed with AES-256-GCM before they reach the database, under a key held in Secret Manager.

Scoped keys & tools

Organization API keys are stored as hashes and expire a year after issue; an agent that claims work receives a token scoped to that work rather than to the organization.

Granular permissions

Twenty-two permission keys per member with per-space overrides, defined once and enforced on both the API and the interface, with a test that fails the build if the two drift.

Runs on your machines

AgentWork and the agent fleet execute on hardware you connect, using your repository access — source code and working files stay in your environment.

BYO-LLM (Enterprise)

Route inference to your own key on any OpenAI-compatible endpoint, so prompts and completions leave through a boundary you chose instead of our platform-managed model.

Tag-pinned releases

Each release is an immutable tag, built once, soaked on a staging environment, then promoted to production as the very same commit — never a rebuild from different source.

Put coding agents to work on your own repos

Point a worker at a local project, equip it with the exact skills and tools the task needs, and let it plan, edit, test, and open a pull request — every step governed and on the record.

1

Bring your own project

Run the agent against a real local repository instead of a throwaway sandbox it can never ship from.

2

Equip it with plugins

Attach Expertise (skills) and Tool sets (MCP connectors) so the worker gets exactly the context and access a task needs — and nothing more.

3

Ship through branches & PRs

Each worker commits to its own branch and opens a pull request, so every agent change lands through the review you already trust.

AgentWork · New Worker

Select a local project

~/acme/payments-service
Migrate the billing webhooks to the new event schema and add tests.
ExpertiseTypeScriptStripe API
Tool setsGitHubPostgres
agent/migrate-webhooks
Planned 4 files
Edited webhooks.ts
Tests 14 ✓
Opened PR #218

Where it runs

The managed service is the deployment we operate and support. Anything else is scoped with our team rather than downloaded.

Managed cloud — the default

We run the platform on Google Cloud in a single United States region. You get the application, the developer API and the hosted MCP endpoint without operating anything.

Self-managed — scoped with us

A Docker Compose deployment of the application, API, database and object storage is documented for teams that want to run it themselves. Packaging, licensing and support for a self-managed install are arranged with our team; there is no self-serve download.

Not offered today

There is no Helm chart or Kubernetes distribution, no air-gapped mode, and no choice of hosting region. If one of those is a requirement, tell us before the evaluation rather than after it.

Questions & answers

What’s included in Enterprise?

Clients (CRM records next to the work), bring-your-own-LLM, higher API and MCP quotas, the audit-log API, custom volumes and dedicated support. Talk to sales to scope a deployment. Worth stating plainly: SAML/OIDC single sign-on, SCIM provisioning and multi-factor authentication are not implemented on any plan, including this one.

How does Enterprise pricing work?

Enterprise is priced per deployment based on seats, usage and support needs — there is no fixed public price. Talk to sales for a quote.

Do you train on our data?

No. Your tasks, plans, runs and content are not used to train shared models. On Enterprise you can also route inference to your own provider endpoint, so prompts need never reach our platform-managed model at all.

What authentication methods do you support?

Email and password with mandatory email confirmation, Google sign-in and Apple sign-in, plus organization-scoped API keys and MCP OAuth for programmatic and agent access. A password sign-in from an unrecognised device must be confirmed with an emailed code. SAML/OIDC single sign-on, SCIM provisioning and multi-factor authentication are not available today.

Can we self-host or run air-gapped?

A Docker Compose deployment is documented, and self-managed installs are scoped with our team. There is no Helm chart, no Kubernetes distribution and no air-gapped mode today — please do not plan around one.

Where does our data live?

In a single Google Cloud region in the United States, in a project separate from our development environment, with no shared credentials between the two. Region selection and EU data residency are not offered today.

Is every agent action audited?

Not yet, and it matters that we say so. Agent traffic that reaches the API — MCP tool calls, organization API keys, connected machines — is recorded at the request level on the same audit trail as any other client, and field changes made over MCP are stamped as such. A first-class per-action record for agent runs is in development.

Do you have SOC 2 or ISO 27001?

No. AgentTask holds no third-party security certification and has not completed an independent audit or penetration test. The trust page publishes the underlying controls, including the ones we do not have, so you can assess us on evidence rather than on a badge.

How do we report a security issue?

Through the published vulnerability disclosure policy, which sets out scope, safe harbour for good-faith research and the response targets we hold ourselves to. The contact is also machine-readable at /.well-known/security.txt.

Send us the questionnaire

We will answer it against the trust page — including the rows marked not available. No badge theatre, no answers we cannot back up.

Talk to our team