AI agents
AI agents need budgets and boundaries, not just a prompt
The interesting question about an AI agent is not only whether it can complete a task. It is also what may happen when it misunderstands that task. A convincing demonstration does not answer this. Once a system can call tools, retrieve information or use paid services, the discussion moves beyond the quality of its text. It becomes a question of operational responsibility, and that requires more than a carefully written instruction.
The assignment is not the permission
A person can interpret an assignment in context and ask when something is unclear. An automated workflow also needs an enforced technical boundary. If you describe permitted destinations but provide broad network access and readable credentials, intention and actual authority diverge. A more capable model does not remove that gap. It may simply make the gap less visible during an ordinary demonstration.
In my open-source project tentaflake, I address this separation through a NixOS template for running isolated agents. Its documented execution setup includes resource limits and restricted network access. The project is still before a stable first release. Its description is therefore not a blanket security promise, and it cannot replace an assessment of the configuration actually used in your environment.
Using a service need not mean holding its key
An agent can use a service without being able to read the secret that authorises access to it. That distinction matters: possession of a key may enable activity outside the intended workflow. A separate service can instead check the current assignment, the permitted operation and the remaining authorised budget before allowing a request. These are different capabilities, even when the successful user experience looks identical.
tentaflake keeps provider keys on the host and treats different control responsibilities separately. For procurement, that means asking for more than a list of connected services. Ask which component grants authority, which enforces it and what happens when that component is unavailable. A diagram or handbook description is useful, but it does not by itself answer how the deployed service behaves under failure.
Research needs its own mandate
In my experimental open-source project tentaflake-research, public web research has a separate, policy-controlled access path. The service checks job ownership and budgets and records provenance for saved evidence. The client does not need its own provider credentials. This makes the research permission explicit, without claiming complete isolation or comprehensive protection against hostile instructions embedded in retrieved material.
A local spending budget also has limits. Reserving an amount internally is not the same as a provider-enforced spending cap. If approval depends on a hard cost boundary, you need to understand both layers. Otherwise, an accurate number in your own system can suggest a financial guarantee that the external service has never made. The difference belongs in the purchasing decision, not in an incident review later.
A contract is not a running control
My open-source project architecture-kit provides tool contracts, requirements and verification examples for agent systems. It is a specification and verification kit, not a deployed agent service. Selecting a profile does not install software or grant authority. This distinction matters because well-developed documentation can easily look like an existing operational product, particularly when its examples are coherent and its terminology is precise.
An approval decision therefore needs a traceable connection between a requirement, an implemented control and an observed result. Synthetic examples can demonstrate the consistency of a contract. Different evidence must establish whether prohibited connections actually fail in the intended deployment. Both forms of work are valuable. The problem begins when evidence answering one question is presented as if it answered the other.
Start with the action that must stop
I would start a purchasing discussion with a refused action rather than the most impressive successful task. What happens when permission is missing, a control is unreachable or a budget is exhausted? An understandable refusal can reveal more than another polished demonstration. It shows whether the boundary exists independently of the agent remembering and choosing to follow an instruction.
This does not mean every decision should be automated. Some actions should deliberately retain human approval. What matters is assigning that responsibility before deployment rather than negotiating it during a failure. The value of an agent is easier to assess responsibly when its assignment, authority, cost exposure and acceptance criteria remain separate, instead of disappearing into a single promise that it will behave well.
Questions for your team or vendor
- Which actions and network destinations can the agent actually reach, and which component restricts that access?
- Where are credentials held, and can the agent read them directly or only request a limited service?
- Which spending limit is enforced by the provider, and which exists only in your local planning?
- What happens when permission is missing, a control service fails or the budget is exhausted?
- Which evidence comes from the intended deployment, and which comes only from synthetic verification examples?
- Who owns permission changes and decides whether the system needs to be approved again?