Connect AI to Business Apps With Least Privilege: A Practical Checklist

Create a dedicated integration identity—not a shared administrator account. Give it access only to the records, fields, actions, environments, and time window required for one workflow. Begin with historical data or read-only shadow mode. Make the AI propose structured actions, validate them deterministically, and require human approval before messages, money, access, deletion, or consequential record changes. Log every read, proposal, tool call, approval, write, error, and reversal.

Write the trigger, allowed inputs, decision, proposed output, system action, owner, acceptance rule, and stop condition. “Help with Salesforce” is too broad; “draft a follow-up from these five approved CRM fields after a completed call” is testable.

Use a service account, managed identity, or narrowly scoped OAuth installation owned by the organization. Do not borrow an employee's token. Name an owner, expiry or review date, credential vault, rotation process, and emergency revocation path.

Expose only required objects and fields. Prefer a curated view or API endpoint over an entire database, inbox, drive, or CRM. Exclude secrets, credentials, health, payment, personnel, legal, safeguarding, and unrelated customer data unless explicitly required and approved. Keep production and test credentials separate.

Replay representative historical cases or run in shadow mode. The integration can read approved context and produce a proposed structured result, but it cannot write. Compare proposals with the actual accepted outcome and record false positives, omissions, unsupported claims, data exposure, abstentions, and reviewer time.

Validate schemas, field types, recipients, domains, amounts, dates, record IDs, allowed transitions, duplicates, rate limits, budgets, and policy rules outside the model. Treat retrieved text and tool output as untrusted input. Do not let model-generated instructions expand permissions or select a new tool dynamically without an allowlist.

Move from read-only to draft, then reversible internal writes, and only later to approved external actions. Require explicit review for customer communication, payments, deletion, access changes, employment or eligibility decisions, legal commitments, and safety-relevant work. Keep a transaction ID and rollback or compensating action for every write.

Log who or what initiated the run, data sources, model and prompt version, tools, proposed and executed changes, reviewer, result, cost, latency, and errors—without copying unnecessary sensitive content into logs. Alert on unusual volume, new objects, repeated failure, retries, denied access, and budget thresholds. Test the kill switch before launch.

Increase permission only when a declared sample meets accuracy, privacy, security, cost, and severe-error thresholds; every exception has an owner; rollback works; and the business outcome improves. Review permissions after workflow, vendor, model, employee, or data changes.

Least privilege is not only a smaller OAuth scope. It is a smaller identity, dataset, action surface, environment, duration, spend limit, and consequence boundary—backed by evidence before expansion.