How AI assistants use your apps — and how to keep it safe

An AI assistant that can only talk is a search box with better manners. The moment it can do things — read your inbox, file a ticket, update a spreadsheet — it becomes genuinely useful and genuinely risky at the same time. Understanding the mechanism, and the small number of habits that make it safe, is worth ten minutes.

What "using your apps" actually means

Under the hood it's a feature usually called tool calling (or function calling). The model doesn't secretly reach into your accounts. Instead, it's given a menu of specific actions it's allowed to request — "search Gmail", "create a Jira issue" — and when it decides one is needed, it produces a structured request naming the action and its arguments. Your software, not the model, actually runs it and hands the result back.

Both major model makers describe it the same way: OpenAI's function calling lets a model "interface with external systems and access data outside its training data," and Anthropic's tool use works on the same request-and-return loop. The emerging Model Context Protocol is just a standard plug for this — "a USB-C port for AI applications" — so one assistant can connect to many apps the same way.

Execution plan
1. jira_search_issues — open tickets assigned to James
2. confluence_search — pages mentioning those tickets
3. Summarise by priority
 jira_search_issues
 confluence_search
You have 4 open tickets — 2 urgent. ONE-42 blocks the release and has a Confluence spec that changed yesterday. Want the diff?
 2 tools · planned first

The important part: the model only proposes. Something between the model and your account decides whether the proposal actually runs. That gap is where all your safety lives.

The real risk has a name

The failure everyone worries about isn't the AI "going rogue." It's more mundane and more common: the assistant is given more power than the task needs, and then something — a hallucination, a confusingly-worded email it read, a malicious instruction hidden in a web page — makes it use that power wrongly.

The security community catalogued this as Excessive Agency, one of the OWASP Top 10 risks for LLM applications. Its three root causes are worth memorizing because they're the whole problem in three words:

• Excessive functionality — the assistant can call actions the task never needed.
• Excessive permissions — those actions run with more access than required.
• Excessive autonomy — high-impact actions happen with no human in the loop.

Note what's not on the list: "the model is evil." The risk is structural. A perfectly well-behaved model with too much reach is the hazard.

The habits that make it safe

OWASP's mitigations aren't exotic — they're the same least-privilege instincts that keep any system safe, applied to an assistant:

• Least privilege. Grant the minimum access the job needs, and nothing spare. If a task only reads, don't hand it the ability to write.
• Minimize scope. Connect the apps you actually use; pin the specific actions a given assistant needs rather than the whole toolbox.
• Human-in-the-loop for anything that changes something. Reading is cheap to get wrong; sending, deleting, and posting are not. Those deserve a tap.
• Run as you, not as a superuser. Actions should execute under your own account and its normal permissions, authorized through OAuth — never a shared key with the run of the house.

gmail · search inboxread-only — ran automatically
gmail · send emailmakes changes — held for approval
Draft ready — send it to the team?Not yetSend

The single highest-leverage habit is the read/write split. Most of what you want an assistant to do — "what are my open tickets", "summarize this thread", "find the invoice" — is read-only, and read-only actions are safe to run freely because the worst case is a wasted request. Writes are where you want a moment of human judgment. Separating the two lets you keep an assistant fast and safe, instead of trading one for the other.

How 1Chat applies this

We built the connection layer around least privilege rather than bolting it on:

• Managed connections run as you — authorized through each app's own login, with your normal permissions, never a shared master key.
• Pin whole apps or single actions. Give an agent everything in an app, or just the two actions it needs. Filter a connection's actions by read-only versus makes-changes, and add all the safe ones in one tap.
• Safe mode is the default posture. Read-only actions run on their own; anything that changes something is held until you approve it — the human-in-the-loop step, built in rather than remembered.

The point isn't to make your assistant timid. It's to make "capable" and "safe" the same setting, so you can connect the apps that make it useful without lying awake about the one action you didn't mean to authorize.