An agent's tool list is not its permission model

A tool list tells you what an agent can try to invoke. A permission model decides which actions it may actually perform, on which room, batch or record, granted by whom and enforced where. To define what an AI agent may read, report or change in your growing operation, define that authority at the execution boundary, not in the prompt.

Describe effects, not tool names

Reading a room's climate history, preparing a report, suggesting a setpoint change and changing that setpoint have different consequences. Damage from excessive agency traces to excessive functionality, permissions or autonomy (OWASP), and a classic case is a read tool connected with broader credentials than it needs. For each action, state the effect class, the resource, the scope, any precondition and the expiry of the grant.

The worked example

Illustrative example, not a real case: an agent is granted read access to one room's climate history for one period and asked to prepare a weekly summary. That grant says nothing about other rooms, batches or sites, and carries no authority to move anything. Changing that room's setpoint is a different power with a different grant, a named approver and its own evidence. What the setpoint should be is your process decision; the permission model decides who may change it and how the change is proven.

Keep granting separate from requesting

The worker asking for an action should not be able to enlarge its own permission. Name who or what grants authority, and the enforcement point that checks the grant on every request. Keep downstream permissions limited to the minimum necessary for the identity the agent uses (NIST), with the system that performs the action enforcing them (OWASP). Expiry alone is not a complete boundary: review credentials, alternative routes, recovery access and the operator's own manual override in the same pass. Tool-design guidance agrees that what a tool can and cannot affect belongs in its contract (Anthropic).

Define what success means

For each consequential operation, state the expected postcondition and the read-back: the setpoint that should be visible for the room, the entry that should appear in the audit trail, the alarm that should clear. An accepted request, a completed action and a confirmed effect are different evidence. Make retries safe: if an acknowledgement is lost, a repeated identical call must not apply the change twice.

Test denial as well as allowance

Verify that the permitted operation works, and that an out-of-scope request is refused by the system that actually enforces the boundary, including the alternative arguments and routes someone might try. A refusal held only in the prompt or the interface is not enforcement.

What to ask

For each action: what is the effect, on which resource, who grants it, where is it enforced, what proves it happened, and what happens when it is refused? A small action-and-resource matrix linked to tests shows an agent's real authority without assuming that tool availability or a confident explanation is permission. This is a design checklist, not a security certification. The briefing side of the same problem is covered in our article on agent task briefs, and keeping decisions visible for operators in our article on dashboards and operator decisions.

If you would rather have this designed and configured for you: the Manna MIND Agentic Server is configured around your growing system so agents work with defined permissions while setpoint changes stay auditable, and the technical operating owner stays in control. To talk through your first scoped agent workflow, contact Manna.

Prepared with AI assistance for Manna Insect Oy.