Who gets to define an AI agent's intent?

The person asking an agent to do work should define its purpose. The organization should decide which actions are permitted while that work happens. An agent can choose how to search, what to read next, and which tool to call, but describing its task more broadly should not give it authority to ignore company policy.

Airlock brings those two inputs together: the agent's declared intent and the organization's rules. In Aaron Tainter's Airlock demo at Agent Night on August 12, an agent requested a token associated with its intent, then used it while working across Linear and Gmail. Airlock checked the proposed calls against that intent and the configured policies. The task explained what the agent was trying to accomplish; the policies still determined whether a particular action could proceed.

For a team adopting this approach, the practical work is to describe an assignment clearly enough to evaluate the agent's choices without trying to predict every step it will take.

Describe the work, including the effects you intend

The billing example on the Airlock product page starts with a request to find last month's duplicate charges and refund them. That gives the agent a purpose, a time period, and an intended change to make. It leaves room for the agent to work out which searches and comparisons it needs.

A request to "help with billing" gives a reviewer much less to work with. It could mean preparing a report, issuing refunds, changing subscriptions, or contacting customers. The person requesting the work should resolve that ambiguity before the agent starts making changes.

A request to "list charges from the last 30 days" is useful when a report is the desired result. If the employee also wants refunds, that instruction leaves the write operation unstated. The task should include the intended effect so the agent does not have to infer whether finding a duplicate also means moving money.

Even a clear refund request does not settle every decision. In Airlock's product example, searching charges is allowed, a refund requires approval, and deleting a customer record is denied because it falls outside the task. Those are separate decisions about actions within the same workflow.

Conceptual illustration of different task scopes against a standing policy boundary. A broader task description must still be evaluated against the same applicable restrictions.

Keep identity and policy outside the task text

A sentence saying "I am acting for the billing administrator" is not proof of that identity. Establish who requested the work through the application's identity controls, then apply the relevant resource permissions and company rules. The task description helps explain an action; it cannot establish the requester's authority on its own.

Our Agent Auth permission-scoping guide makes a related distinction between intent and authority. A caller's description of the work gives an authorization system context to evaluate alongside permissions.

Policy also needs to express restrictions that remain relevant across assignments. A rule prohibiting financial information in outgoing email should still apply when an agent is asked to write a detailed summary. Calling the assignment "prepare a comprehensive update" does not remove the restriction on what the email may contain.

Use a real action to check whether the task is clear

The Agent Night demo provides a useful example. An ordinary planning update to a manager went through. In a later request, the agent found a Linear issue about LLM token usage and composed an email summarizing it. Airlock denied the send because the body contained token-spend information, which the configured policy treated as financial data.

Both workflows involved reading Linear and sending email. Knowing which tools were connected would not have explained the different outcomes. The contents of the proposed email mattered, along with the work the employee had requested and the policy governing that content.

Apply that reasoning to a workflow your team already runs. Write down who requested it, which resources it concerns, and what changes the employee expects the agent to make. Then give another person a few proposed actions and ask which belong in the assignment. If one person thinks issuing a refund is included and another thinks the task ends with a report, clarify the task before relying on it as authorization context.

Treat a changed assignment as a decision

An employee may legitimately expand the work, for example by asking the agent to examine another month of charges. Record that change and evaluate the new actions against the same applicable permissions and policies. A revised assignment can introduce more work without changing who has authority to approve a refund.

An agent paraphrasing a denied request needs a different response. If the recipient, content, and intended effect remain the same, softer wording should not be enough to make a prohibited send acceptable. Include that case in your evaluation: submit a disallowed action, reword its description, and check both the new decision and whether anything happened at the provider.

Semantic checks can vary with wording, so this is behavior to test rather than a guarantee to assume. Clear intent gives those checks useful context, while enforceable permissions and policies provide the restrictions the workflow still has to satisfy.

Sign up to try Airlock.