LLMMoat Start a conversation

Field Note 001

Before you give an AI assistant access, test what it cannot do

A narrow task does not require broad account access. Start with the job, remove unnecessary permissions, and test the actions the system should reject.

· Security and supervised AI

One illuminated authorized doorway surrounded by closed pathways
Useful access should be narrow by design. Every other path should remain closed until there is a reason to open it. Editorial illustration generated with OpenAI.

A business owner wants an AI assistant to handle one repetitive task. The software asks for access to the whole account.

This happens often. The task may be small, but the default integration is broad. An assistant that only needs to send an approved message may also request permission to read the inbox, search old conversations, manage contacts, or act without review.

The easy response is to accept the defaults and move on. The safer response is to ask a different question:

What must this assistant be unable to do?

Start with the job, not the integration

Write down the exact action before connecting anything.

"Help with email" is too vague. "Send a message after a person approves the recipient, subject, and body" is specific enough to design around.

Once the action is clear, remove permissions that do not support it. If the assistant does not need to read incoming mail, do not connect the inbox. If it should contact only known recipients, restrict the recipient list. If every message needs review, do not enable automatic sending.

This approach can feel slower during setup because it requires decisions that a one-click connection avoids. It is usually faster when something goes wrong. Fewer permissions mean fewer places to investigate and fewer ways a mistake can spread.

A successful test is not enough

Suppose the assistant sends an approved message and it arrives. That proves the allowed action works. It does not prove the restriction works.

You also need a negative test: an action the system should reject.

Can the assistant send to an unapproved address? Can it read a message it was never authorized to open? Can it change a contact, download an attachment, or trigger another system from the contents of an email?

The answer should come from a real test, not from the wording on a settings page.

During a recent LLMMoat setup, a recipient restriction looked correct but rejected an approved test message. Two systems interpreted the same address differently. We corrected the policy and tested it again.

The interesting part was not the email. The test showed that the written rule and the enforced rule were not identical.

A configuration screenshot can document intent. It cannot prove behavior.

One approved route through a system while alternative routes stop at enforced boundaries
A positive test proves the approved route works. Negative tests prove the boundaries hold. Editorial illustration generated with OpenAI.

Keep public messages outside the control channel

A public contact address will receive messages from people you do not know. Some will be spam. Some may contain links, attachments, urgent requests, or instructions written to sound authoritative.

Treat all of it as untrusted input.

An email should not authorize an assistant to run a command, open a file, change an account, contact another person, or reveal internal information. That remains true when the sender claims to be the owner, a customer, a vendor, or technical support.

Public inquiries and internal operations should use separate channels. People can review the public inbox manually. If a legitimate request needs action, an authorized person can move it into the normal approval process.

This separation is simple, but it blocks a dangerous shortcut: turning "someone sent an email" into "the assistant has permission to act."

Leave unnecessary features turned off

Automation tools make it easy to add inbox monitoring, webhooks, automatic replies, contact forms, databases, and background workflows. Each feature may be useful. Each one also creates another path that needs authentication, logging, monitoring, and recovery.

Do not enable a feature because it is available. Enable it when a defined workflow requires it and someone is prepared to own the risk.

A manual step is not always technical debt. Sometimes it is the control that keeps an uncertain process from becoming an autonomous one.

Remove temporary access when the work ends

Setup and maintenance often require permissions that the finished workflow does not.

Remove or disable that access after deployment. Then test the result from both directions: the service should remain available, and the old maintenance path should no longer work.

This matters because temporary access has a habit of becoming permanent through neglect.

A practical review before launch

Before connecting an AI assistant to a business system, answer these questions:

  1. What single action does the assistant need to perform?
  2. Which permissions are necessary for that action?
  3. Which permissions can be removed?
  4. Who approves an external action before it happens?
  5. What test proves the allowed action works?
  6. What test proves a forbidden action is blocked?
  7. Are public messages treated as untrusted input?
  8. Where are actions logged and reviewed?
  9. How will access be revoked if the workflow behaves unexpectedly?
  10. Which temporary permissions must be removed after setup?

If those questions do not have clear answers, the integration is not ready.

The goal is not to make an AI assistant powerful. It is to make one useful action predictable, observable, and reversible. Everything else can wait until there is a reason to grant it.