How do I give my agent its own API key to an internal app?

TL;DR

Give your agent a key that belongs to it, not your session and not a project-wide secret. On floo, you mark which routes accept a key in floo.app.toml, create a named consumer, and mint a key with a scope and a rate limit. The gateway checks the key, strips it, and tells your code which consumer called.

Internal apps now have two kinds of users. People use the UI. Your agent reads and updates the same data through the API.
A good agent credential has four properties: limited to what it needs, rate-limited, revocable on its own, and logged.
Most platforms only offer the whole project. Supabase secret keys bypass row-level security, and Vercel's bypass secret covers every deployment in a project.
On floo, people and programs share one app with separate doors: sign-in for people, scoped keys for programs.

The first version of an internal app is usually a page for people. A week later the agent that built it is also its heaviest user. It updates stock counts from an email, pulls a weekly report, or closes out tickets it resolved. At that point the app needs to let a program in without letting everyone in.

Why not just use my own login?

Because then the agent is you. It can do everything you can, its requests look like yours in the logs, and the only way to cut it off is to sign yourself out. A project-wide secret has the same problem at a larger scale: anyone holding it has the whole project.

A credential for an agent should be:

Limited to the routes or operations the agent needs.
Rate-limited, so a loop in the agent cannot flood the app.
Revocable on its own, without signing out a person or rotating everyone's secret.
Logged, so you can see what it called and when.

What do common stacks offer?

From each vendor's docs, read on October 22, 2026:

Supabase has publishable keys, which respect row-level security, and secret keys, which bypass it. Every secret key has full project access. A narrower agent credential means minting your own JWTs or building a key table.
Vercel Deployment Protection lets programs through with a protection-bypass secret, and that secret covers every deployment in the project.
Replit's built-in private deployment gate blocks machine callers, so an agent key means making the app public and writing auth yourself.
Cloudflare Access service tokens are the closest match: a scoped, revocable credential per caller.

We traced the same app across 15 platforms.

How does floo do it?

First, declare which routes accept a key. People keep signing in everywhere else:

[[routes]]
path = "/"
service = "web"
access = "accounts"

[[routes]]
path = "/agent/v1"
service = "api"
access = "api_key"
scope = "stock.write"

Then create a consumer for the agent and a key with that scope:

floo apps consumers create stock-agent
floo apps keys create stock-agent --consumer stock-agent --scope stock.write --rate-limit-rpm 60

The raw key is shown once. Pipe it straight into the place the agent reads secrets from, and keep the key ID for revocation and request history. It never needs to appear in a chat transcript.

When the agent calls /agent/v1, the floo gateway checks the key against the route's scope and the rate limit. It strips the key before the request reaches your code and passes the verified consumer instead, so your app knows the call came from stock-agent without validating anything. A revoked or unknown key gets a 401, a key without the route's scope gets a 403, and a key over its rate limit gets a 429. Sending a key to a route that only accepts people does not sign the caller in.

App keys belong to one app and grant no access to floo itself. An agent holding one can update stock counts. It cannot deploy, read your env vars, or open another app.

What does this change in practice?

You can let the agent do more because you can see and stop exactly what it does. If it misbehaves, revoke its key. The revocation reaches every gateway within 30 seconds, and the people using the app notice nothing. If you add a second agent for reporting, give it a second consumer with a scope that covers only the report routes. Each request is listed by key ID with its method, path, status, and latency, so "what did the agent call last night" has an answer.

This is the split we think every internal app needs now: a UI for people, an API for agents, and a separate door for each.

What are the limits?

Scopes are attached to routes you declare, and GET and POST on the same route share one scope. Record-level permissions stay in your code.
Request history is kept for about seven days and is for visibility, not a lossless audit log of data changes.
If your org or app has an approval policy that gates access broadening, adding machine access to an existing invite-only app needs an org admin to apply it.
The raw key cannot be retrieved after creation. Lose it and you mint a new one.

The app API keys guide has the full reference, including request history and revocation.

Sources

floo: app API keys, app sign-in, multi-service routing
Supabase: API keys
Vercel: protection bypass
Replit: private deployments
Cloudflare: service tokens

Frequently asked questions

Should my agent use my login or its own key?

Its own key. A key tied to one consumer can be limited to specific routes, rate-limited, revoked on its own, and audited separately from people. Sharing a person's session or a project-wide secret gives the agent everything that person or project can do.

How do I limit what an agent's key can do?

On floo, declare the routes that accept machine access in floo.app.toml with access = "api_key" and a scope, then create a key for a named consumer with that scope. The key works only on routes declared with its scope.

Can an invite-only app still accept API calls?

Yes. On floo, people sign in on the routes marked access = "accounts", and programs present a key on the routes marked access = "api_key". Revoking a key signs no one out.

Does my app have to validate the key?

No. The floo gateway checks the key, strips it before the request reaches your code, and passes the verified consumer's identity instead.

Can I see what the agent did with its key?

Yes. floo keeps a request history for each app key, so you can list the requests a key made by its key ID.