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: October 23, 2026
Version: 1.1

This page describes WorkerKit's security controls and their limits. It is the overview referenced by Sections 2.3 and 7 of the Privacy Policy.

This overview does not create additional warranties, certifications, or contractual commitments. Our commitments are governed by the Terms of Service, the Privacy Policy, and any applicable signed agreement, including a Data Processing Agreement. Nothing here limits those commitments or obligations imposed by law. Capitalized terms have the meanings given in the Terms.

No system can prevent every unauthorized disclosure, mistaken action, or loss. Workers can act on live accounts, and security controls reduce risk without eliminating it. Consider the consequences before connecting an account, granting write access, or supplying sensitive data. See Sections 6, 7, 20, and 21 of the Terms.

1. What You Are Trusting Us With

A Worker can use the access you grant to read and change data in your apps. Depending on its permissions and integration, it may send messages, edit records, or delete content. Two categories of data matter:

• Credentials. OAuth tokens, API keys, and other secrets used to authenticate to an App Provider or Model Provider. These can provide continuing access until they expire or are revoked.
• Content. Instructions, run prompts, material read from apps, tool arguments and results, Model Inputs and Outputs, reports, and stored memory or records.

App data may reach the Model and other tools used during a run. Do not assume that personal or sensitive data is automatically removed before it reaches a Model, a destination app, or a stored record.

2. Credentials

• Storage and use. The Service stores Credentials needed for your connections and BYOK model access, and uses them to authenticate requests, refresh authorization, and operate the features you use. Stored BYOK model-provider keys use application-level encryption. Credential handling differs across integrations and sign-in flows; this overview does not claim that every stored credential has separate application-level encryption.
• Worker permissions and shared connections. A Worker's access token defines its permissions. The underlying app connection or credential may be shared by multiple Workers or authorized users in the same account; a separate Worker key does not mean a separate provider credential.
• Provider permissions. OAuth access is bounded by the authorization the provider grants. API keys and other credential types follow that provider's permission model. Check the permissions of the actual credential; WorkerKit's settings do not change what a stolen provider credential could access directly.
• Removing access. Revoke or disable Worker access when it is no longer needed. Deleting or revoking a Worker does not by itself delete a shared app connection or revoke its credential at the provider. Disconnect the app separately, and use the provider's own controls to revoke its authorization or rotate its key when needed.
• Revocation has limits. Provider behavior, cached authorization, and requests already in progress can affect when revocation takes effect. Revocation does not recall data already delivered or undo actions already completed.

Credential handling and deletion are also addressed in Sections 2.3 and 8 of the Privacy Policy and any applicable DPA.

3. Access Controls and Their Limits

WorkerKit checks requests against Worker permissions and the controls supported by the integration. The available restrictions vary by app and tool.

• Apps and operations. Configure the apps a Worker may use and the operations it may perform. Read access can still disclose data to a Model or another permitted destination.
• Narrower restrictions. Some integrations support resource, entity, contact, or field restrictions. Do not assume that a folder, recipient, domain, or field is restricted unless that restriction is supported and configured for the integration you use. Installing a Kit does not create a custom allowlist of resources or contacts.
• MCP and custom integrations. Permission to call a tool is not a guarantee about that tool's internal behavior. A third-party tool may use broad credentials or send data to destinations its operator controls.
• Source-IP rules. Supported account and Worker IP rules can run in audit or enforcing mode. Audit mode observes without blocking. Hosted execution can be explicitly allowed to use WorkerKit's egress, so an IP rule should not be treated as proof that every run originates on your network.
• Permission changes. Narrow or revoke permissions when needed. Changes cannot recall data already sent, undo completed actions, or guarantee that a request already in progress will stop.

Grant the narrowest access that does the job, start with read access where practical, and test with low-impact data. Review a Kit's requested access and the Worker's actual settings before its first run and after changes. These controls do not guarantee that a particular disclosure, action, or loss will be prevented. See Sections 6.4 and 20 of the Terms.

4. Content During and After a Run

Hosted execution processes content to carry out your instructions and sends relevant content to the Models and tools used for the run. Storage is not limited to an optional transcript:

• Run and activity records. We record operational information such as timing, actions, outcomes, Model usage, errors, and cost. These records may include content, such as subjects, recipients, identifiers, and error details. They are not guaranteed to be a complete record of every action.
• Prompts and reports. Run prompts, reports and summaries, questions and answers, and evaluation results or explanations may be stored to support the run history, follow-up runs, and review or improvement features. Turning off transcript storage does not turn off all content storage.
• Transcripts. New supported hosted deployments default to seven-day transcript storage, with exceptions such as Workers with protected instructions. Review the Worker's actual deployment setting before running. A shortened transcript can still contain personal or sensitive data; truncating a result is not anonymization or redaction.
• Memory and records. Content written to Worker memory, shared records, or a destination app persists separately from a transcript. Review and delete it through the relevant controls when no longer needed.
• Evaluation and improvement. Automated checks may process run content and retain scores, explanations, findings, or proposed changes. These features should not be treated as a guarantee of transient or zero-retention processing.

We do not use your Inputs, Outputs, Connected Account data, or Operational Metadata to train generative AI models. This describes WorkerKit's use; it is not a promise about every third-party provider's data practices.

The Privacy Policy and any applicable DPA address processing and retention obligations. Transcript settings apply to transcripts, rather than to all data held by the Service or by a provider.

5. Platform and Operations

WorkerKit uses authenticated account access, permission checks, HTTPS for its public service endpoints, and operational logging. Account and resource authorization checks are designed to restrict access to the appropriate account and authorized users. Credential storage includes encryption mechanisms, but this overview does not claim uniform coverage, independent per-account encryption keys, or a particular key-management standard.

These are application controls in a shared service, not a dedicated environment or a guarantee of isolation from every defect or attack. Encryption at rest does not mean end-to-end encryption: the Service and the providers involved must process plaintext to perform the work.

This overview does not promise a particular backup schedule, recovery point, recovery time, data residency, or availability level. Any specific requirement should be addressed in an applicable written agreement. Keep independent copies of important data and consider whether actions in connected apps can be reversed.

6. Kits and Security Checks

A directory listing, scan result, score, or popularity metric is not a certification or endorsement of a Kit's safety or suitability.

WorkerKit may apply automated checks, security scans, or moderation to Kits. These checks are limited: they can miss harmful instructions, unexpected behavior, prompt injection, and risks that arise only with your data or connected tools. They do not establish that every Kit or update has received a comprehensive security review.

Before installing a Kit:

• read its instructions, requested apps and permissions, and intended destinations;
• inspect the permissions actually granted to the Worker, including any shared connections or other Workers it may call;
• start with limited access and low-impact data, and review initial runs before expanding access.

Report suspicious or misdescribed Kits to security@workerkit.ai. Creator responsibilities and prohibited conduct are addressed in Sections 4 and 5 of the Terms and Section 12 of the Acceptable Use Policy.

7. Third-Party Integrations and Prompt Injection

MCP servers, API endpoints, webhooks, gateways, websites, documents, messages, and tool responses can supply content a Worker uses. Untrusted content can contain instructions intended to redirect the Worker. A trusted service can also be compromised.

Prompt injection can lead to unintended actions or disclosure through tools the Worker is permitted to use. Access controls constrain available operations; they do not reliably determine whether every permitted action matches your intent. Read access to sensitive data combined with access to an external destination can create a disclosure path.

Data sent to an external provider is subject to the applicable terms and processing arrangements. Our deletion controls cannot remove copies held independently by that provider. Connect only services you trust, limit the data and permissions exposed, and verify important actions. See Section 6.9 of the Terms and Section 4 of the Privacy Policy.

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 any applicable DPA.

Contact security@workerkit.ai promptly if you suspect compromise. Disable affected Workers, revoke the relevant Worker or manager keys, and revoke or rotate affected credentials directly with the provider. Check connected apps for actions already taken. These steps limit further exposure but do not guarantee that all activity has stopped or that prior actions can be reversed.

9. Reporting a Vulnerability

Send suspected vulnerabilities to security@workerkit.ai. Include the affected feature, a minimal reproduction, and the potential impact. Do not send live credentials or unnecessary personal data in the report; ask for a suitable transfer method if sensitive evidence is necessary.

Section 12 of the Terms governs security research and requires prior written approval for penetration testing, vulnerability research, red teaming, prompt injection testing, and other adversarial testing against the Service. Request approval with the proposed scope, method, timing, and accounts involved. Approval is limited to its written scope and conditions. This page does not independently authorize testing or grant a separate safe harbor.

Do not access, modify, or exfiltrate another user's data, disrupt the Service, or test third-party systems without their authorization. If you encounter another person's data unexpectedly, stop testing and report the issue without collecting further data. Give us a reasonable opportunity to remediate before public disclosure, as required by the Terms.

We do not currently operate a paid bug bounty program. Reporting an issue does not create an entitlement to payment or a guaranteed response or remediation deadline.

10. Your Responsibilities

• Protect your sign-in account and enable the security protections your identity provider offers.
• Keep Worker and manager keys confidential; review their scope and revoke unused keys.
• Review who can administer the account, manage connections, or access Workers and records. Remove access when someone leaves.
• Review Worker activity and stored content, and disable a Worker that behaves unexpectedly.
• Grant only access and data you are authorized to provide. Section 2.7 of the Privacy Policy addresses sensitive data.
• Assess the effect of writes, messages, deletions, and external disclosures before enabling them. Some cannot be reversed.

11. Compliance and Provider Arrangements

• This page does not claim SOC 2 attestation, ISO 27001 certification, or compliance with a particular security framework. Contact security@workerkit.ai for current evidence before relying on a compliance requirement.
• The Service is offered only in the United States, as described in the Terms and Section 1.3 of the Privacy Policy. That offering restriction is not a data-residency guarantee for all providers or integrations.
• Providers may be accessed through your credentials or through platform-funded access, depending on the feature and billing mode. Do not assume that every request uses a provider account you hold directly. Review the applicable provider and processing arrangements for your use.
• Privacy and contractual questions, including DPA availability and information about service providers, can be directed to privacy@workerkit.ai. This overview does not determine a provider's legal role or extend a provider's commitments.

12. Changes to This Page

We update this overview as the Service changes. Updating this page does not amend a signed agreement or remove commitments under the Terms, Privacy Policy, or applicable law. Required notices are governed by those documents, including Section 1.4 of the Privacy Policy.

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