WorkerKit Security

How we protect what you connect, and the parts of that only you can do. A description of practice, not a contract.

Last Updated: August 3, 2026
Version: 1.0

This page describes how WorkerKit protects the accounts and data you connect to it. It is the page referenced by Section 2.3 and Section 7 of the WorkerKit Privacy Policy.

This page is a description of our current practices, not a contract. Our binding commitments are in the Terms of Service, the Privacy Policy, and, for customers who sign one, the Data Processing Agreement. We update this page as our practices change, and nothing here creates a warranty or guarantee. Capitalized terms have the meaning given in the Terms of Service.

We do not promise that WorkerKit is secure. We work hard at it, everything described below is real, and none of it is a guarantee. No system of this kind can be made safe against every threat, and we would rather say so here than let you infer a promise we cannot keep. Security measures reduce risk. They do not remove it. If that is not a risk you are willing to take with a particular account, do not connect that account. If it is not a risk you are willing to take at all, do not use WorkerKit. Sections 20 and 21 of the Terms of Service say this in the language that binds, and nothing on this page overrides them or adds to them.

1. What You Are Actually Trusting Us With

We would rather state the risk plainly than lead with reassurance.

WorkerKit is not a chatbot. A Worker holds live authorization to accounts you already own, and it takes actions in them: it reads mail, writes records, moves files, sends messages, and deletes things. That means two categories of data matter here, and they are not the same:

• Credentials. The OAuth tokens, API keys, and secrets that let a Worker authenticate as you to an App Provider. This is the most sensitive data we hold. A Credential is not a copy of your data, it is standing access to it.
• Content. The material a Worker reads from and writes to a Connected Account while it runs, and the Inputs and Outputs exchanged with the Model you selected.

The controls below are organized around that split, because losing a Credential and logging a paragraph are different failures with different consequences.

2. Credentials

• Encrypted at rest, and isolated per account.
• Used only to authenticate the requests a Worker you configured makes to the App Provider you authorized, and to maintain and refresh that authorization.
• We do not use Credentials to access your accounts for our own purposes. We do not access a Connected Account except as directed by a Worker you configured, or as necessary to operate, secure, troubleshoot, or lawfully investigate the Service.
• The scopes attached to a Credential are the ones you selected when you authorized the connection. We cannot widen them without sending you back through the provider's own consent screen.
• One Worker, one key. Each Worker carries its own key and its own list of what it may open. A Worker cannot reach through another Worker's connections, so narrowing or stopping one leaves the rest working.
• Deleted when you disconnect the account, delete the associated Worker, or delete your account, on the timeline in Section 8 of the Privacy Policy.
• Revocable at any time, both here and directly with the App Provider. Revoking at the App Provider invalidates the Credential immediately, whatever our systems do.

3. The Access You Grant Is the Access It Has

The strongest security control on this platform is not one of ours. It is how narrowly you grant access in the first place, and the product is built so you can grant very little.

• Per app, per Worker. Every connected app on a Worker is set to no access, read, or write. A Worker cannot reach an app you did not connect for it.
• Inside an app. You can pin a Worker to specific folders, calendars, mail labels, boards, and channels, rather than the whole account.
• Who it may deal with. You can list the people and email domains a Worker is allowed to read from and write to. Contact outside that list is refused.
• Where it may be driven from. Source-IP allowlists are available per Worker and account wide, in audit or enforcing mode.
• Reversible. Narrow a permission or switch it off at any time. The Worker keeps running with whatever is left, and never quietly regains what you removed.

Grant the narrowest access that does the job. A Worker that files invoices needs the Invoices folder, not your Drive.

These are controls you configure, and like every control they are tools rather than guarantees. We do not warrant that any of them will prevent a particular disclosure, action, or loss, and none of them is a substitute for scoping access narrowly, testing before you rely on a Worker, and watching what it does. Section 6.4 and Section 20(i) of the Terms of Service are the binding statement of that.

4. Content During and After a Run

• In transit for execution. Content a Worker reads is processed in memory to build the request sent to your selected Model, and Outputs are processed to carry out the Worker's actions. We keep no persistent copy of this content for execution purposes.
• Run metadata is always recorded. Timestamps, the Kit and Worker involved, the accounts and endpoints touched, the actions attempted and their outcome, the Model used, token counts, errors, and cost. Retention varies by plan.
• Logging the content of Inputs and Outputs is off by default and requires opt-in. In an Organizational Account, your Admin User controls it for the organization.
• Outcome scoring is transient. Where we score whether a run did the job the Kit says it does, the content is processed in memory, is not stored or logged, is not reviewed by a person, and is not used to train anything. Only the resulting score is kept. This is described in Section 3.2 of the Privacy Policy and Section 10.7 of the Terms.
• Retention is published. The full table, per data category and plan, is Section 8 of the Privacy Policy.

We do not train generative models on your Inputs, Outputs, Connected Account data, or Operational Metadata. Evaluation is measurement, not training.

5. Platform and Operations

Our current technical and organizational measures include:

• Encryption of data in transit over public networks, and encryption of Credentials at rest.
• Access controls and authentication requirements for our personnel, with production access restricted to the people whose role requires it.
• Logical separation of customer environments, so one account's Workers, Credentials, and configuration are not reachable from another's.
• Logging and monitoring of access to production systems and of Service activity.
• An incident response process, described in Section 8 below.
• Encrypted backups on a rotation, with deleted data overwritten on the ordinary backup cycle.

This list describes what we do. It is not a commitment to a security standard, a certification, or an outcome, and it may change as our systems change. No method of transmission over the internet and no method of electronic storage is completely secure, and we do not guarantee absolute security. See the statement at the top of this page and Section 20 of the Terms of Service.

6. Kits Are Not Reviewed

This belongs on a security page because it is the thing most likely to be assumed wrong.

WorkerKit does not review, audit, verify, certify, or endorse the Kits in the directory. Kits are third-party content, provided as is. Install counts, stars, success rates, and rankings are measurements of observed activity, not a review, and a Kit with favorable numbers is still an unreviewed third-party Kit.

Before you install one:

• read what it says it does, the apps it uses, and the access each one asks for, all of which are on the Kit's own page;
• grant the narrowest access that works, and start it in read only where the job allows;
• watch its first runs before you widen anything.

Report a Kit that misdescribes itself, requests access it does not need, or behaves maliciously to security@workerkit.ai. Sections 4 and 5 of the Terms of Service and Section 12 of the Acceptable Use Policy set the rules Kit Creators are held to.

7. Integrations You Add Are Not Reviewed Either

You can connect third-party services we never selected or onboarded: MCP servers, gateways, webhooks, endpoints, and other integrations you or your organization supply. Doing that is entirely your call, and it is the fastest way to widen what a Worker can reach.

We do not review, test, verify, or endorse any of them, and we cannot see what their operators do with the data a Worker sends. Two things about them are worth understanding before you connect one:

• The data leaves us. Once a Worker sends something to an integration you added, that integration's operator holds it under its own terms. Our retention rules, our deletion timelines, and our commitment not to train on your data do not reach it.
• It can talk back to your Worker. An integration returns content and tool definitions that a Worker acts on. A hostile or compromised one can therefore try to steer a Worker into doing something you did not ask for. This is prompt injection, it is a real and unsolved class of attack, and connecting an integration means accepting it.

Connect only what you trust, give it the least you can, and watch what it does with the first runs. Section 6.9 of the Terms of Service is the binding version of this section.

8. Incidents

If we become aware of a personal data breach affecting your personal data, we notify you and any applicable regulator as required by law, and within the timeframes in the Data Processing Agreement for customers who have one.

Tell us immediately at security@workerkit.ai if you believe your WorkerKit account or a Connected Account has been compromised. If a Connected Account is involved, also revoke WorkerKit's access at the App Provider directly. That takes effect immediately and does not depend on us.

9. Reporting a Vulnerability

Send security reports to security@workerkit.ai. Include what you found, how to reproduce it, and what an attacker could do with it.

Section 12 of the Terms of Service governs security research. In short: test only accounts and data you own or have written permission to test, do not access, modify, or exfiltrate anyone else's data, do not degrade the Service, do not use a finding for any purpose beyond demonstrating it, and give us reasonable time to fix an issue before disclosing it. Research conducted within those limits is authorized, and we will not pursue you for it.

We acknowledge reports and work them by severity. We do not run a paid bug bounty program at this time.

10. Your Side of It

Some of this is only yours to do:

• keep your account credentials confidential and turn on the protections your identity provider offers;
• grant Workers the narrowest access that works, and revoke access you no longer need;
• review Worker activity, and disable a Worker that is doing something you did not intend;
• in an Organizational Account, keep your Admin User list current, and remove people who leave;
• do not put data into the Service that you are not permitted to process there. Section 2.7 of the Privacy Policy covers sensitive data.

11. Compliance Posture

Stated plainly so you do not have to infer it from what is missing.

• We do not currently hold a SOC 2 or ISO 27001 attestation. If your review process requires one, write to security@workerkit.ai and we will tell you where we are.
• The Service is offered only in the United States, and is operated from Austin, Texas. See Section 1.3 of the Privacy Policy.
• A Data Processing Agreement is available for organizational and commercial customers.
• We disclose the categories of service providers we use in Section 4.1 of the Privacy Policy, and provide the specific list to customers on request at privacy@workerkit.ai.
• App Providers and Model Providers are not our service providers. You hold the relationship with them directly, under their terms, on your own account. We move data at your direction between you and services you already use.

12. Changes to This Page

We update this page as our practices change, and we do not treat it as amendable-only-by-notice the way the Terms and the Privacy Policy are. If a change reduces a protection described here in a way that materially affects you, the Privacy Policy's notice provisions in Section 1.4 apply.

13. Contact

WorkerKit
10900 Stonelake Blvd
Austin, TX 78759, United States

• Security and vulnerability reports: security@workerkit.ai
• Privacy: privacy@workerkit.ai
• Legal: legal@workerkit.ai
• Support: support@workerkit.ai