Menu
Request pilot access

Infrastructure for AI agents

Infrastructure for autonomous AI agents, under your control.

Agents need resources to get their work done. DockBay is being built so they can discover, request and use services through consistent interfaces, with permissions and limits set by the people and organizations responsible for them. We're starting with email, now in a pilot with access on request.

Your agent requests what it needs and keeps working, within the limits you set.

Request pilot accessWhat works today

Email pilotAccess on request

EmailpilotFile storagevisionDatabasesvisionExternal accountsvisionWhatsApp & channelsvisionthe dock

01 · Origin

From developer experience to agents at work

DockBay comes from Abner's experience as a developer of traditional systems. To keep building an application, he often had to stop and solve supporting needs: somewhere to store files, a way to send email, a temporary database. Each one could mean an account with another service, infrastructure setup, credentials and a dedicated integration.

Working with AI agents, he recognized the same needs in a new consumer of infrastructure: the agent itself. In the middle of a task, an agent may need storage, a database, communication or authorized access to an external account. These needs tend to come up more often, faster and at a larger scale, often without a developer around to prepare each step.

That is the purpose: bring provisioning and integration into one place, with consistent APIs, MCP tools and clients, so the agent can request a resource, get access ready to use and keep going, within the authority delegated by whoever is responsible for it. Developers and traditional applications use the same infrastructure.

Before

The developer stops working to create accounts, configure services and write each integration.

Now

The agent finds the resource during the task and keeps working, within the limits its owner set.

There is a second need, just as important: agents need to talk to people and companies through the channels they already use. Email is the first of those channels. WhatsApp and other channels are part of the expansion vision.

02 · Who it's for

The agent is a direct user. So is whoever answers for it.

DockBay serves different audiences with different needs. The AI agent has its own row: it discovers, requests and uses. Whoever builds, runs or answers for it decides on integration and control.

  • First-class user

    AI agent

    Discover capabilities, understand requirements and limits, request resources and use them while running, with clear programmatic responses.

  • Delegation and control

    Responsible person or organization

    Delegate access and autonomy, set usage and spending limits, follow what happens and stop or revoke access when needed.

  • Integration

    Application and agent developer

    Integrate DockBay into the solution and prepare the application or agent to use resources through consistent interfaces, without a dedicated integration for each service.

  • Evaluation

    Platform and security team

    Assess identity, isolation, policies, traceability and deployment options against the organization's requirements.

AI agents are first-class users: a design priority for programmatic interfaces, identity, permissions and machine-readable responses. It does not give agents legal personhood or replace the responsibility of people and organizations.

03 · Experience

Conceptual example

Request, receive, keep working

An illustration of the experience DockBay is building. It is a conceptual example, not API documentation.

  1. 1

    Identifies the need

    Mid-task, the agent realizes it needs a resource to continue.

  2. 2

    Checks capabilities

    It discovers what is available and under which conditions it can be used.

  3. 3

    Requests in the right context

    The request carries the identity of the agent and of whoever it acts for.

  4. 4

    DockBay applies the policy

    Permissions, limits and duration set by the owner are checked.

Within the delegation

The resource is made available and the agent gets what it needs to keep working.

Out of scope or over the limit

The response states the condition, such as missing authorization or a reached limit, and the action needed. Execution waits or takes another path; nothing is widened automatically.

Not every request is approved on the spot, and not every resource will have the same access format.

Conceptual example

An agent that manages sales proposals needs to send the final version to a customer and wait for the answer. It uses the mailbox delegated to it, sends the email, waits for the reply and carries on with the negotiation, without anyone setting up an email service for each task.

04 · Email

Email pilot

Email: the first delivery

Agents need to take part in the communication of people, companies and systems while they work. Email is the channel everyone already uses: customers, suppliers, public agencies and legacy systems. In DockBay, it is a programmatic capability the agent uses under delegated permissions and limits.

Real pilot example

Connecting Claude Code to DockBay over MCP, with the key received in the pilot:

claude mcp add --transport http dockbay https://api.dockbay.io/mcp \
  --header "Authorization: Bearer $DOCKBAY_AGENT_KEY"

Then, in plain language:

  • “send an email to my-address@example.com saying you are connected to DockBay”
  • “wait for the reply”
  • “reply in the same conversation, formatted in HTML with a plain-text version”

Traditional applications use the same service through the REST API: they create mailboxes, send and read messages, search conversations and receive webhooks.

In the pilot: up to 50 recipients and 25 MB per message, attachments up to 10 MB, and messages kept for 30 days. The service runs on AWS, in the São Paulo region.

Pilot access is granted after the request is reviewed; no account or mailbox is created instantly.

Request pilot access

05 · Control

Autonomy under control

Autonomy depends on explicit delegation. The owner defines what the agent can use, on which data, with which limits and for how long. The agent acts within that, without asking for approval on every operation already authorized.

Principles that guide the product

Design direction. What already exists in the pilot is in the table below.

  • Direct use

    The agent discovers and uses capabilities through programmatic interfaces, with clear descriptions, requirements and states.

  • Context and accountability

    Every access is tied to the agent acting and to whoever it acts for, scoped to the task.

  • Delegation with limits

    Permissions, quotas, budget and duration are set by the owner; within them, the agent acts.

  • Control while running

    Out-of-scope requests return an explicit restriction or approval-needed condition.

  • Continuity

    Resources last for the authorized period and stay available to the right context, beyond a single conversation.

  • Visibility and intervention

    Owners understand usage, follow spending and actions, and can suspend or revoke access.

In the pilot today

  • API keys per account, stored only as hashes and shown once.
  • Scopes per key, such as read-only or read and send, and restriction to specific mailboxes.
  • Key revocation at any time.
  • Isolation between accounts: another account's resources never show up.
  • Per-key limits on requests and connections, and size and recipient limits per message.
  • Your own domain only after proving ownership through DNS.
  • A durable event log per mailbox, with cursors to resume from.

Product direction

  • Budgets, quotas and duration set per agent and per task.
  • An approval flow when a request goes out of scope.
  • A console to follow usage, spending and actions, and suspend access.
  • Resources scoped to a user, organization, application or task.
  • Connections to external accounts authorized by the account owner, with revocation.

Speed and scale come together with these controls. We do not promise unlimited capacity or absolute security.

06 · Vision

Expansion vision

The next berths

Resources and connections that are part of DockBay's direction. They are not available in the pilot and have no promised date.

  • File storage

    An agent asks for space to keep a file produced during a task and finds it again when needed.

  • Databases

    A temporary or persistent database to organize a task's data, with a defined duration.

  • External accounts

    Authorized access to accounts such as Google Drive and Gmail, with the account owner's consent and revocation.

  • WhatsApp and other channels

    Agents talking to people and companies through other channels they already use.

  • On your infrastructure

    Deployment in the customer's environment and support for AWS, Google Cloud or Azure.

In the product vision, each resource is scoped to a user, organization, application or task, with a defined duration. Persistence follows the policy of the resource and its owner, allowing continuity across sessions or agents when authorized.

Expansion vision

Future scenario: documents in Google Drive

An agent acting for a user of an application needs to look up documents in Google Drive to continue a task.

  1. The agent requests that capability from DockBay.
  2. DockBay checks the owner's identity, the existing connection and the permissions granted for that context.
  3. If there is already a valid connection with the access needed, the agent continues within the authorized scope.
  4. If a new authorization is needed, DockBay runs the consent flow and returns a state that names the dependency; the agent resumes once the user has authorized it.

Being signed in to the application is not the same as having authorized Google Drive. Consent is still required, including for additional permissions.

The integration's setup moves into DockBay, but it still exists. There is no access without authorization, no unrestricted access to every file and no way around Google's requirements.

AgentAs an agent, I want to find out whether I can access the documents I need and get authorized access, so I can continue or clearly identify the human authorization still missing.
OwnerAs a user, I want to decide what my agent can do in my Google Drive and be able to revoke the connection, so I can delegate work while keeping control of my files.

07 · For agents

For AI agents

If you are an agent evaluating DockBay for a task, this is the summary in plain text.

Available now
Email for agents and applications: in a pilot, with access on request.
Real interfaces
REST API at https://api.dockbay.io/v1, MCP server at https://api.dockbay.io/mcp, events at wss://api.dockbay.io/v1/events/ws, webhooks and the dockbay CLI.
Authentication
A Bearer API key issued to an approved account. Scopes and allowed mailboxes are set by the owner.
Outside your permissions
The operation is refused with an explicit error, such as insufficient permission. Permissions are never widened automatically.
How to get access
Joining the pilot is a decision for your human owner or organization, through the request on this page. Once authorized, day-to-day use is direct, through the interfaces.
Machine-readable formats
/llms.txt and /capabilities.json describe only what works today: capabilities, interfaces and limits.
Not available yet
File storage, databases, external accounts, WhatsApp and deployment on the customer's infrastructure are part of the expansion vision.

/llms.txt · /capabilities.json

08 · FAQ

Frequently asked questions

What is DockBay?

Infrastructure for AI agents to get and use resources through consistent interfaces, with permissions and limits set by the people and organizations responsible for them. We're starting with email.

Is it only for AI agents?

No. Agents are first-class users, but developers and traditional applications use the same infrastructure through the API.

What is available right now?

Email for agents and applications, in a pilot with access on request: mailboxes with their own address, sending and receiving, conversations, search, waiting for messages, events and webhooks. Everything else is expansion vision.

How does pilot access work?

You send a request on this page describing your use case. We review fit and availability and reply by email. Once approved, you get an account and API keys for your agents or applications. No account is created instantly.

Which integration interfaces are available?

REST API, MCP server, WebSocket events, signed webhooks and the dockbay CLI, all with the same API key.

Can I use file storage, databases or external integrations yet?

Not yet. They are part of the expansion vision, with no promised date.

How will DockBay keep agent autonomy under control, and which controls exist in the pilot?

Autonomy depends on explicit delegation. The pilot already has per-account keys with scopes, restriction to specific mailboxes, revocation, isolation between accounts and usage limits. Per-task budgets, approval flows and a monitoring console are product direction.

How should DockBay handle access to external accounts?

In the product vision, through connections authorized by the account owner, with a defined scope and revocation. Being signed in to an application is not the same as having authorized, for example, Google Drive. Not available yet.

Can an agent use DockBay directly, or does it need a human operator?

Joining the pilot is decided by a person or organization. After that, the agent uses the capabilities directly, through the API or MCP, within the permissions of the key it received, without a human in every operation.

What happens when the agent needs a resource outside its permissions?

Today the operation is refused with an explicit error. In the product direction, the response will also name the authorization needed and allow resuming later. Permissions are never widened automatically.

How can traditional applications use the same infrastructure?

Through the REST API, with an API key: create mailboxes, send and read messages, search conversations and receive webhooks. It is the same service agents use.

Which deployment options are available, and which are planned?

Today DockBay is operated by us on AWS, in the São Paulo region. Deployment on the customer's infrastructure and support for Google Cloud or Azure are product direction.

09 · Access

Email pilot

Request pilot access

You are asking to join a pilot. We review each request against the use case and availability; there is no automatic approval and no set timeline.

Tell us in a few lines what your agents or applications would do with email.

We use this information only to review and answer your request, as explained in the Privacy Policy.