Agent200

Security

Access that is scoped
by design.

An agent that interacts through connectors acts on someone’s behalf. Agent200 ensures every action is tied to a specific end user, limited to what you configured, and bounded by the permissions granted by each provider.

  • Per user

    Every user-specific operation runs against one end user's own connections.

  • Per permission

    You choose the services, endpoints and scopes your app may use.

  • Per provider

    The external service enforces exactly what its user granted and nothing more.

Read this first Every run() Agent200 executes is scoped three ways: to a specific end user, to the endpoints you enabled, and to what the provider granted that user. The rest of this page walks through how each of those boundaries is enforced.

Identity

A request only ever uses one user's connections.

The user-to-connection mapping is the foundation of the platform's identity model. Your API key identifies your app; it never stands in for a person.

A request made for user_123 uses only the Slack and Gmail accounts that user_123 authorized. The connections that belong to user_456 in the same project are not used.

Request from your app

agent200.user("user_123").run({ … })

  1. 01 The request names the end user it runs for.
  2. 02 Agent200 looks up that user's connections in your project.
  3. 03 Tools execute with those credentials, and no one else's.
Conceptual interface

Developer project

  • user_123 Used for this request
    • Slack account A resolved for this request
    • Gmail account A resolved for this request
  • user_456 Not used
    • Slack account B isolated from this request
    • Gmail account B isolated from this request
Every call names its user
A user-specific operation is always associated with an end-user identity that your app supplies. Agent200 resolves that identity to the connections the person authorized.
Connections are never pooled
A request made for user_123 uses user_123's own connected accounts. It never reaches credentials that belong to user_456, even inside the same project.
Your users don't need Agent200 accounts
End users interact with your product. They meet Agent200 only when they authorize one of their own external accounts.

In the examples on this site, agent200.user("user_123").run(…) is how a request names its user. Every user-specific operation carries that identity.

Permissions

Three layers have to agree.

Permissions operate at more than one level. A tool executes only when the necessary configuration, authorization and provider permission are all present.

  1. Layer 1 · You, the developer

    Decide what the app may request or execute

    In the dashboard and, where supported, the SDK, you enable services, pick individual endpoints and select the OAuth scopes. Search Gmail but never send; read Slack but never delete.

  2. Layer 2 · Your end user

    Authorizes access to their own account

    Private data is reachable only after the person who owns the account has approved the connection on the provider's own consent screen.

  3. Layer 3 · The external service

    Enforces what it granted

    The provider's API has the final word. Agent200 cannot give an agent access the external service has not authorized, and provider restrictions always apply.

  4. Only then does the tool run. If any layer says no, the operation is not executed.

Example permission configuration. Slack: search messages and retrieve messages are allowed; send messages and delete messages are blocked. Gmail: read emails is allowed; send emails and delete emails are blocked.
Endpoint permissions Concept

Slack

  • Search messages read Allowed
  • Retrieve messages read Allowed
  • Send messages write Blocked
  • Delete messages write Blocked

Gmail

  • Read emails read Allowed
  • Send emails write Blocked
  • Delete emails write Blocked

This configuration determines what Agent200 may expose to the model or execute for your app. You also select the OAuth scopes each connector requests.

OAuth

Where authorization happens, and where credentials live.

For supported connectors, Agent200 runs the OAuth process (callbacks, token storage and token refresh where applicable), so your app never has to receive, store or rotate your users' provider tokens itself.

  1. End user

    Opens the authorization link from your app.

  2. Provider consent

    Approves access on the external service's own OAuth page.

  3. Agent200 callback

    The provider redirects to an Agent200-controlled domain.

  4. Stored for that user

    The connection is associated with the specific end user.

  5. Kept current

    Tokens are refreshed where the provider supports it.

One API key ≠ blanket access

Your key authenticates your app. It never bypasses a user's authorization.

An Agent200 API key gives access to the capabilities permitted in its project or environment, and removes the need for separate model and paid-service keys. It does not unlock anyone's private account data: that still requires the account owner's consent.

Authorization is not unlimited

Actual access is the intersection of four things.

  • The permissions the end user granted.
  • The services, endpoints and scopes you configured.
  • What the external provider's API exposes.
  • Any restrictions the provider applies.

When authorization is missing Agent200 returns an authorization-required response with a URL you present to the user in your own interface, or you hand the user to the hosted authorization experience. Either way, nothing runs against an account until its owner has approved it.

Data handling

What Agent200 stores, and what only passes through.

This is an architectural boundary, not a slogan. Here is exactly which side of it each kind of information falls on.

Persisted

What Agent200 stores to operate

The platform cannot authenticate your app, act for the right user or bill correctly without keeping this.

  • Developer accounts and project configurations
  • API key records, or securely stored credential representations
  • OAuth connection information and tokens
  • End-user-to-connection mappings
  • Connector and workflow configurations
  • Usage and billing information

Passing through

What it does not keep

Data retrieved through connectors is processed in the execution flow and returned. Agent200 does not maintain a persistent, searchable database of what your users' connected accounts return.

  1. Slack API returns messages
  2. Execution flow processed temporarily
  3. AI model same run() request
  4. Your app receives the result

Temporary processing is unavoidable: to answer a request, a connector result has to be passed to the model during the same execution.

A storage boundary, not a "zero retention" slogan.

Agent200 does not keep a persistent store of the data your users' connectors return. Handling that data for the length of an execution is part of answering the request, which is why this page describes a boundary instead of promising zero storage. If your review needs the retention and logging detail, ask us.

Environments

Keep production apart from everything else.

Agent200 supports multiple projects and environments. Each environment can have its own settings, integrations and credentials, so an experiment in development never runs with production access.

Scoped keys An API key belongs to one environment, so a key issued for development never reaches production connections.

Project · productivity-agent (illustrative)

  • development

    own credentials

    Try connectors and workflows against test accounts.

    • Settings
    • Integrations
    • Credentials

  • staging

    own credentials

    Rehearse a release with its own configuration.

    • Settings
    • Integrations
    • Credentials

  • production

    own credentials

    Real users and real connections, with its own credentials.

    • Settings
    • Integrations
    • Credentials

Before you build

Bring these to the conversation.

Security reviews differ from one company to the next. If your project depends on a specific answer in any of the areas below, raise it with us before you build and we will go through it with you.

Data and platform posture

Operational logging
What Agent200 records during a run and who inside Agent200 can read it.
Ask us
Temporary retention
How long data in flight lives before it is discarded.
Ask us
Encryption
How stored credentials and configuration are protected.
Ask us
Access controls
Who inside Agent200 can reach which systems, and how that access is governed.
Ask us
Data deletion
How developers and end users have their information removed.
Ask us
Compliance commitments
The frameworks and attestations your own review requires.
Ask us

Execution safeguards

Limits, retries and timeouts
The bounds placed on a run() request and its tool calls.
Ask us
Error handling
How failures in a provider or a workflow surface to your app.
Ask us
Approvals
Confirmation requirements for sensitive operations before they execute.
Ask us

Start the conversation.

Send your question or report through the contact form and choose "Security report" so it reaches the right people. Every message is read by a person who can go through the detail with you.

Get in touch
200 OK

Give your agent access.
Keep it scoped.

You decide what your app may do. Your users decide what it may touch. Agent200 executes inside both.

Get Started Explore integrations