The deploy line.

01 / Identity

A conversation is not an identity boundary

Start with the person or service principal behind the request, the organization they belong to and the account they intend to change. A name in a message is useful context. It is not proof of identity, membership or ownership of the target record.

In the credit example, the execution context needs to identify the acting user, the business tenant and the billing account. Those relationships should come from verified identity and trusted account mappings. They should not be reconstructed from whatever the model happens to remember about the conversation.

Keep that context attached through the whole path. Switching tools, resuming a conversation or delegating work must not silently turn a user-scoped action into a broader service action. If the account relationship is missing or ambiguous, stop at that boundary and ask for the information needed to resolve it.

02 / Authority

Approval belongs to a particular change

“Yes, go ahead” needs a concrete object. In our example, that object includes a $12,000 credit, a named billing account, a reason and the intended operation. If the account or amount changes after approval, the earlier confirmation no longer covers the new proposal.

Make the proposed action inspectable before asking for a decision. Store the approved parameters, or a stable representation of them, with the decision. At execution time, compare the actual operation with that approved proposal and evaluate the current policy. This is a design pattern, not a substitute for the authorization rules of your business system.

A connection being available does not mean every connected action is allowed. A user who can read an invoice may not be able to issue a credit. An administrator may have revoked access while the request waited. Keep authentication, permission and human approval distinct, and check the applicable authority immediately before the change.

03 / Credentials

Use the intended credential for the intended service

The conversation should carry the intention to act, not the secret that makes acting possible. Resolve the appropriate connection inside the trusted execution boundary. Check its tenant, account, audience and required scope before making the downstream call.

This is also a protocol boundary. An access token presented to an MCP server is not a general-purpose token to forward to an unrelated business API. The MCP security guidance explicitly forbids token passthrough. The OAuth security best current practice calls for restricting access-token privileges, including their resources and actions.

Those two primary references are useful starting points: MCP security best practices and RFC 9700, access-token privilege restriction. Your provider’s own authorization contract still matters. Do not infer that a token is appropriate because a request happens to succeed.

Keep credentials out of prompts, tool results, client-visible payloads and diagnostic logs. Error handling needs the same care as successful execution: a failed request must not become a convenient way to expose an authorization header.

04 / Execution

A timeout is a question, not permission to repeat

Now return to the credit. The billing system might have committed the change before the network connection failed. From the assistant’s point of view, no result arrived. From the business’s point of view, money may already have moved. These are different facts.

Give the logical action a durable identifier before dispatch. If the provider supports idempotency, use the same key for retries of that same action, within its documented retention and request-matching rules. A new random key on every attempt gives the provider a new action to execute. A stable key alone does not create a guarantee that the provider has never promised.

When the outcome is ambiguous, check the authoritative system using the reference it supports. If you can verify the credit, record the confirmed result. If you can verify that it was not applied, follow the provider’s retry contract. If neither is possible, preserve the uncertainty and route it to an operator with the context needed to investigate.

The interface is part of this design. “We’re checking whether the credit was applied” is an honest status when that is what the system is doing. A success message before verification creates a promise you cannot yet support. An immediate “try again” can invite a duplicate.

Cancellation has a similar boundary. Stopping further attempts does not necessarily undo an external change that already completed. Describe what stopped, what is known to have happened and what remains unresolved. That distinction belongs in both the execution record and the customer-facing status.

05 / Evidence

Leave a record that someone can use

If the customer disputes the credit a week later, the conversation transcript is only part of the answer. You need the acting identity, the policy decision, the approved parameters, the attempted operation, a safe connection reference and the outcome observed in the authoritative system.

Connect those records with the logical action identifier. Distinguish an intention from an attempt and an attempt from a confirmed result. Preserve the timestamps and policy context needed to explain why the action was allowed at that moment. Record only the information necessary for that purpose, under an appropriate access and retention policy.

Evidence does not mean storing everything. Bearer tokens, credentials, sensitive request data and continuation tokens should not become audit artifacts. The record should help an authorized operator answer what happened without handing them a second set of secrets or exposing another customer’s data.

Then test the uncomfortable cases: a changed amount after approval, revoked permission while waiting, a response lost after commit and a repeated request arriving through another session. The useful question is whether the system preserves the same business intention and reports the outcome accurately under those conditions.

Pick one action and draw its deploy line

You do not need to start by auditing every possible tool. Pick one operation that changes something consequential. Walk it from proposal to approval, from approval to execution and from execution to evidence. Give each boundary an owner.

Ask what happens when the response disappears. Ask whether the approval still matches the dispatched parameters. Ask which identity and credential reach the final system. Ask whether someone outside the original conversation can reconstruct the result. If the answers are vague, a more capable model will not make those boundaries clearer by itself.

This is the argument behind the deploy line. Models and interfaces can change. The business’s obligations to its customers continue. That is where dependable AI software needs a durable foundation.

For the business-owner view, read Your AI can answer. Can your business stand behind the answer? To discuss a workflow in your own systems, talk to Noodle Seed.