Here is what happens today when you give an AI agent access to an external service. You generate an API key. You paste it into the agent's configuration. The agent now has the same access you do. No limits. No expiration. No audit trail. No spending cap.
If the agent malfunctions, it can burn through your entire API budget in minutes. If the agent is compromised, the attacker has your key. If you forget to revoke the key after the task is done, it sits there, live, indefinitely.
This is not a theoretical risk. It is the default workflow for every agent deployment I have seen in the wild. And it is the problem Till was built to solve.
The raw key problem
API keys were designed for a world where the entity using the key was a known, trusted application controlled by a known, trusted human. The application was deployed once. It ran in a predictable environment. The human monitored it. If something went wrong, the human revoked the key and investigated.
AI agents break every one of these assumptions.
An agent is not a static application. It makes decisions at runtime about which APIs to call, how often, and with what parameters. A self-evolving agent running on something like the Adaptive Convergence Protocol changes its own behavior over time. The agent you gave the key to last week is not the same agent using the key this week.
An agent is not always controlled by a single human. In multi-tenant deployments, one agent instance might serve multiple customers, each with different authorization levels. A raw API key does not know which customer's request it is serving. It just authenticates.
An agent does not stop when you stop watching. It runs continuously. If you give it a key to a metered API and go to sleep, you are trusting the agent's judgment about how much to spend. If that judgment is wrong, you find out when the invoice arrives.
A raw API key is an unlimited power of attorney with no expiration date. That is fine when the holder is a simple script that does one thing. It is reckless when the holder is an autonomous agent that makes its own decisions about what to do next.What Till does
Till is an activation-limited API key proxy. Instead of giving an agent your real API key, you give it a Till key. The Till key wraps your real key with constraints.
Activation limits. The key works for a defined number of calls, then it stops. Not rate-limited. Stopped. The agent cannot exceed the boundary no matter what it decides to do.
Token budgets. For LLM API calls, Till tracks token consumption and enforces a ceiling. When the budget is spent, the key deactivates. No surprise invoices.
Spend caps. For metered APIs with dollar-denominated costs, Till enforces a maximum spend. The cap is per-key, so different agents or different tasks can have different budgets.
Per-tenant isolation. In multi-tenant deployments, each tenant gets their own Till key with their own limits. One tenant's agent cannot consume another tenant's budget. The isolation is at the key level, not the application level.
Audit logging. Every call through a Till key is logged. Which agent, which API, which endpoint, how many tokens, what time. When something goes wrong, you do not have to guess what happened. You look at the log.
Instant revocation. A Till key can be revoked in one call. The underlying API key stays active for your other uses. Only the agent's access is cut.
The comparison in practice
Picture a concrete scenario. You are running an AI agent that handles customer support. The agent needs access to your CRM API, your email API, and an LLM API for generating responses.
With raw keys, you paste three API keys into the agent's configuration. The agent can now read your entire CRM database, send emails to anyone, and generate unlimited LLM completions. If the agent hallucinates a response and sends it to a customer, you find out when the customer replies. If the agent enters a loop and makes ten thousand LLM calls in an hour, you find out when the bill arrives.
With Till, you create three scoped keys. The CRM key allows read access to customer records but not bulk export. The email key allows sending to verified customer addresses only. The LLM key has a daily token budget of fifty thousand tokens. If the agent tries to exceed any of these boundaries, the key stops working. You get a notification. The agent gets a clear error.
The agent is still autonomous. It still makes decisions. But those decisions happen inside a boundary that you defined, and the boundary is enforced at the infrastructure level, not by trusting the agent to police itself.
Why this matters for the agent economy
The self-evolution architecture that makes agents powerful is the same architecture that makes unconstrained access dangerous. An agent that gets better every day is an agent whose behavior changes every day. The access controls that were appropriate last week might not be appropriate this week.
Till keys are designed to be short-lived and narrowly scoped. You issue a key for a specific task, with a specific budget, and when the task is done, the key expires. The agent earns access to the next task by completing this one within bounds. That is a fundamentally different trust model than "here is the master key, I trust you."
Every serious deployment of autonomous agents will eventually need something like this. The question is whether you build the access control layer before or after the first incident. I would rather build it before.
Till is live and accepting early users. You can also find it in my startup portfolio. The keys work till they do not. That is the point.