04/AI Security · Authorization · Backend·3 min read
Giving AI Tools Without Giving It Uncontrolled Power
Tool-using AI should propose intent. Authorization, confirmation, and side effects belong to deterministic backend code.
agentic should not mean unrestricted
“Give the model tools” is incomplete advice. Tools are side-effecting APIs. If the model can call them freely, you have built an untrusted planner with production privileges. That is not leverage. That is an incident waiting for a prompt.
A safer shape separates proposal from execution. The model may interpret a customer request and propose an action. Deterministic backend code decides whether that action is allowed, whether confirmation is required, and how to execute it idempotently.
VaaniDesk was built around that separation for multilingual customer support: conversations can drive business actions, but sensitive operations do not execute because the model sounded sure.
ownership checks and confirmation gates
Authorization for tool actions should look like ordinary backend authorization. Ownership checks, role checks, and resource scope come from the authenticated principal and server-side state — not from whatever account number appeared in the latest user message.
Confirmation before sensitive operations turns irreversible or costly actions into an explicit human decision. Cancellation, refunds, and similar flows need an approve/deny step that the UI can represent clearly. The model can request confirmation. It should not silently complete the side effect.
Idempotency protects against retries, double submits, and repeated tool proposals for the same intent. Support workflows are noisy. Without idempotency keys and server-side deduplication, “controlled” actions become duplicated charges and duplicated state transitions.
tool boundaries and prompt injection
Tool/action boundaries define the closed set of operations the system will consider. An open-ended “run whatever seems helpful” loop is difficult to reason about and harder to evaluate. A catalogued action set can be tested, logged, and denied by default.
Prompt injection is the adversarial version of the same problem: untrusted text tries to elevate privileges or coerce tool use. Defences include treating retrieved and user content as untrusted, keeping privileged instructions separate, and ensuring the tool gateway never trusts the model’s word over server-side policy.
None of this requires claiming a general autonomous agent framework. It requires boring backend discipline applied to AI-shaped entry points.
auditability as part of the action path
If an action can change customer or business state, it should leave an inspectable trail: who requested it, what was proposed, what checks ran, whether confirmation occurred, and what executed. Observability is not only for model quality. It is for operational trust.
When something goes wrong, you want to replay the decision path without reconstructing it from chat poetry. Structured logs and evaluation coverage over security-critical cases make that possible.
VaaniDesk’s verification posture treated security-critical evaluations and end-to-end browser checks as part of release readiness for exactly this reason: controlled actions are product behaviour, not a demo flourish.
the contract worth keeping
Give the model a narrow channel to express intent. Keep authorization, confirmation, idempotency, and execution in code you can test without asking a provider to be lucky.
That contract scales down to internships and small teams as well as it scales up in complexity: fewer magical loops, more explicit boundaries, and fewer ways for fluent text to become unauthorized power.
If you only remember one design rule: the model can suggest. The backend must decide. Everything else — confirmation UX, idempotency keys, audit events, evaluation cases — is how you keep that rule true after the first demo stops being carefully supervised.
This is also why evaluation cases for sensitive actions matter. A suite can assert that a cancellation proposal without confirmation does not mutate state, that ownership mismatches fail closed, and that repeated identical tool proposals do not double-apply. Those tests are not glamorous, but they are how “controlled” stays true after refactors.
Fluent models will keep getting better at sounding authorized. Your job is to make sure sounding authorized never becomes being authorized.
Related: VaaniDesk case study →