Security

How AGNT isolates users, protects credentials, keeps people in control of consequential actions and handles untrusted content, and what you are responsible for.

AGNT assistants read a user's mail and calendar, message other people, place calls and operate a workspace (the user's cloud computer) on that user's behalf. Every user's data is isolated from every other user's, every credential is hashed or encrypted, and every type of consequential action can require a person's approval, with an account-wide kill switch above it. This guide states those guarantees and the controls you configure.

Controls at a glance

User isolation

An account is your app on AGNT. It holds all of your end users, who are unrelated to each other, so data is isolated at the user boundary, not the account boundary.

• Tasks, chats, memories, contacts, calendars, approvals and workspaces belong to a user. A request acting as one user cannot read or change another user's.
• A user-scoped key acts only as its own user for approvals and edits.
• An account-wide API key is your server's trusted credential. It can list, read and delete tasks and chats across all of your users, for support and admin tooling. Keep it on your servers.
• An X-User-Email that does not resolve to a user in your account is refused. A failed scoping check never falls back to account-wide access.
• A certificate JWT authenticates only the account whose certificate signed it.
• Collaboration is explicit. Another person sees a task only when added to it as a collaborator, and only the task's owner can approve what it sends.

Organizations and teams group users for administration and policy. They do not share data. See Users, organizations and teams.

Credentials

Give a client that acts for one user a user-scoped key, and revoke keys you no longer need. See Authentication for creating, scoping and revoking keys.

Human approval and the kill switch

Autonomy is set per user and per action type: email as the user, email as the assistant, messaging, calls, calendar, drive, files, contacts, connected apps and publishing a site. Each runs automatically (auto), after a review window (time-boxed), or only on approval (manual). New users start with only actions taken as the user, and publishing a site, on manual. For enterprise use, set the rest to manual or time-boxed and lock them at the organization. See Autonomy for the defaults table.

• Approval binds content. An approval carries a hash of what the approver saw. If the staged content changed since, the approval is refused and nothing is sent.
• Nothing runs between approval and execution. No model runs after approval. The stored actions execute as shown.
• A person approves. Approval requires a person's own session or an API key acting as that person. Certificate (SDK) tokens cannot approve, edit or cancel.
• Undo. Reversible actions can be reverted within a window. Irreversible ones can be held for a delay during which they can still be cancelled.
• Admins enforce with locks. Organization and team admins can lock an action type to a mode. A lock overrides the user's own setting, per-task overrides and every recipient exception except a block, and the assistant cannot change it. Where several locks apply, the most conservative wins. Without a lock, the assistant can tighten a task's mode but never loosen it.
• Kill switch. One account-wide switch freezes every outbound action and all new task work for every user. Only a person signed in to your hosted app can engage or release it. The console, API keys, certificates and service tokens cannot, so a leaked credential cannot release a freeze.

See Tasks and approvals for the approvals API.

Untrusted content

Assistants read content written by people other than the user: inbound email, web pages, shared documents and replies from strangers. Any of it can contain instructions aimed at the assistant.

• Untrusted content is labelled. Inbound mail, web pages and documents reach the model marked as untrusted: data to work with, not commands to follow.
• Unknown senders cannot instruct the assistant. A message from an unknown sender is gated before the assistant acts on it. It cannot direct the assistant to act for the user.
• Unusual requests are held for the owner. A request from an outside party that the user would not expect is held for the user to decide.
• Approval cannot be bypassed. An action prompted by untrusted content goes through the user's autonomy settings and admin locks like any other. Content cannot approve a pending action or release the kill switch.

Inbound email authentication

Mail to AGNT-hosted assistant mailboxes is dropped before any assistant sees it when:

• spam or virus checks fail,
• DMARC fails for a sender domain that publishes p=reject, or
• SPF and DKIM both fail.

Mail that passes these checks still reaches the assistant as untrusted content.

Webhooks

• Inbound. Messaging webhooks (Slack, Twilio, WhatsApp) are verified by signature or shared secret and refused if the credential is missing. Calendar and mailbox change notifications are treated as untrusted pings and the data is re-fetched.
• Outbound. Payloads are signed with HMAC-SHA256 in X-Agnt-Signature.

Plugins and workspaces

• Plugins you author run in an isolated sandbox with no access to platform secrets.
• Only you, the developer, can add code that runs on the platform. End users cannot author plugins or point a skill at a package, repository or start command.

Each user's workspace (browser, desktop and shell) runs in its own container, has no public IP address, is torn down when idle, and keeps user files in per-user directories. Your commands, files and the browser run as an unprivileged user.

The restricted security preset turns off and locks MCP servers (including custom ones), the workspace shell, browser automation and workspace handoff. Apply it to the account in the AGNT console, or to one team through the API. See Users, organizations and teams and Computer use.

Identity

See SAML SSO and SCIM 2.0 for setup.

Admin controls

Policy is layered from your account down to organizations and teams. A lower tier can change a setting only where no tier above has locked it. For capability switches and access levels, the most restrictive value at any tier applies.

See Policy.

Audit

• Administrative actions are recorded as audit events: organization, domain, SSO, membership, role and policy changes, and SSO sign-ins. Actions by a signed-in user, or an API key acting as one with X-User-Email, who belongs to a team in an organization with audit logging enabled are recorded. Account-wide key calls without X-User-Email and SCIM changes are not.
• Events are archived nightly. The API serves the most recent 30 days.
• Export any time range to your own S3 bucket through an IAM role you control, with a trust policy limited to the AGNT account that delivers audit exports. See Export audit events to S3.
• Memories, contacts, companies, preferences (including autonomy settings) and tasks keep a revision history that can be listed and restored.

Data retention and deletion

• Revision history is hard-deleted after a retention window, 90 days by default.
• Deleting a user removes their data. Deleting an account removes the account, its members, certificates and tasks. Contact support for full erasure.

Compliance

AGNT is audited annually against SOC 2 Type II. Contact [email protected] for the report.

Shared responsibility

Report a vulnerability

Email [email protected] with a description, reproduction steps and the affected endpoint or surface. Do not access data that is not yours while testing.

See also

• Authentication
• Tasks and approvals
• Users, organizations and teams
• Computer use