Your automation should not have access to everything

Hey,

On June 27, I showed you the automation I use to check our 9 production environments. It runs every morning at 5 AM, while I am sleeping, and stays quiet if there is nothing to report.

Quave ONE has 121 MCP tools today. That automation needs five.

So here is the very simple security question: should it have access to the other 116 just because it probably will not call them?

No.

An automation that checks logs should not be able to deploy, and one that checks whether your backups exist should not also get the tool that downloads them.

So this week we added a new way to authorize MCP keys: By tool.

Give the agent only the tools it needs

MCP keys can now use one of two authorization modes:

• By permissions keeps the scope-based model we already had. It remains the default, and existing keys continue working without any reconfiguration.
• By tool creates an explicit list of the individual MCP tools that key can use.

When you choose By tool, the MCP client sees only the tools you selected, and Quave ONE blocks everything else before it runs. If we add a new tool next week, your key does not receive it automatically.

This matters most for automations that run by themselves. A confirmation dialog helps when you are sitting in front of Cursor or Codex, but it cannot protect something that runs alone every morning. The limit has to live in Quave ONE itself, and now it does.

Here is a practical example. For an automation that checks every production environment for new errors, I can select only:

• get-current-account
• list-apps
• list-app-envs
• get-account-observability-summary
• get-app-env-log-error-summary

Five tools out of 121.

On my account, the automation can compare those 9 environments with their normal baseline and look for new error patterns. It cannot change an environment variable, scale a container, trigger a deploy, reveal a secret, or delete anything, because none of those tools are available to its key.

The same idea works for other jobs:

• A backup audit can receive list-app-env-backups without get-app-env-backup-download.
• A deployment automation can receive only the JobRun and deployment tools used by its release flow.
• A compliance automation can read members and account activity without receiving unrelated infrastructure actions.

In the dashboard, create or edit an MCP key and choose Authorization mode → By tool. Search by name or choose a feature group, then remove anything the automation does not need. Quave ONE saves the exact tool list, so future tools stay blocked until you add them.

This controls whole tools, not individual arguments. Normal account, app, and environment permissions still decide where a selected tool can act, and the protections for secrets, dangerous operations, admins, MFA, and audit data still apply.

The full behavior is in the MCP documentation.

That is the main update this week. We also shipped a startup command override and added more build capacity, two smaller changes worth knowing about.

One image, two ways to start it

We also added Startup command overrides for Apps and Functions.

A container image has a default command, but the same image can often do more than one job:

Image default: bun run start:api
Worker environment: bun run start:worker

Before, you could change the Dockerfile or build another image just to start a different process. Now the startup command belongs to the app environment. The API environment can use the image default while the worker environment overrides it, even when both use the exact same image.

Open an environment, expand Advanced settings, and find Startup command. You can set a complete command, exact arguments, and a working directory. The same configuration is available through the CLI, Public API, and MCP.

Saving the startup command creates a pending deploy change, so you can apply it immediately or include it in the next deployment.

The override stays with the environment across new image versions, redeploys, and rollbacks. The startup command is runtime configuration, not part of the image. Changing only that command does not require a different image, and Quave ONE can reuse an equivalent build artifact.

This is useful for a few common cases:

• Run an API and a queue worker from one image.
• Start different processes from the same monorepo build.
• Set the correct working directory when the application does not live at the image root.
• Reuse one image you already tested across environments without maintaining almost identical Dockerfiles.

Jobs already have their own command configuration, so this override is for regular Apps and Functions. Do not use a startup command for a migration or a one-off script either, because it will run again every time the container starts. Use a Job for that. And please do not put passwords or tokens in a startup command. Keep secrets in secret environment variables.

See the examples and exact behavior in the Startup Command documentation.

Builds got slower, so we added capacity

The third change is less visible, but you probably feel it more directly: builds were getting slower.

Some projects take much longer to build than others, and they were starting to slow down the shared build path. That is ours to handle. A slower build should not become something you simply learn to live with.

So we added another dedicated build machine that we can route affected accounts to, with a BuildKit-enabled build path. It gives us more room for concurrent work, and BuildKit can reuse unchanged layers when caching applies. The goal is simple: less time waiting for a builder and less repeated work.

There is also a message here that is more important than the machine: if Quave ONE suddenly feels slower, tell us.

A large first build may naturally take longer than a small one. But if your build usually takes 3 minutes and suddenly takes 12, do not assume that is normal. Reply to this email or open Support in the dashboard with the account, app, environment, and approximate time. We will inspect it.

We monitor the whole path from source upload to a running app, but one report from you can expose a slowdown before our platform-wide numbers make the impact obvious. We want to know, fix it, and stop the slower behavior from becoming normal.

To wrap up

The MCP key is the main change I want you to try. Create one By tool key for your next automation and make the list as small as possible. If one image currently needs two almost identical Dockerfiles, try a startup command. And if a build feels slower than it should, reply and tell us.

Have a great week and go enjoy the people you love.

Abraços,
Filipe