Least privilege for AI agents and integrations

An AI agent connected to your business systems can read, write, send and delete at machine speed. That is the point of connecting it, and it is also the risk. A model that misreads an instruction, or a document that carries a hidden one, can do exactly as much damage as its credentials allow.

So the most useful security decision in an AI integration is made before any prompt is written: what is this system allowed to touch? Least privilege answers it simply: only what the task needs, only for as long as it needs it, and with a record of who granted it.

Scope credentials to one customer and one source

A single master key that reaches every customer’s data is convenient in a demo and dangerous in production. Instead:

• One credential per customer, per source system. If a key leaks or an integration misbehaves, the damage stops at one customer’s connection to one system.
• Separate keys per environment. Development, staging and production never share credentials. A test script should be unable to reach live records, not just told not to.
• Encrypted at rest, never in code. Keys live in a secrets store or an encrypted column, load at runtime, and never appear in logs, prompts or error messages.

Read-only by default

Most AI features only need to read: summarize a case, score a call, answer a question from a knowledge base. Ask for read-only scopes when you connect a system, and add write access only when a specific feature needs it and someone has agreed to it. When the source system offers fine-grained scopes, request the narrowest set that covers the job, not the “full access” checkbox.

Short-lived tokens

Where the provider supports OAuth2, use access tokens that expire in minutes or hours and refresh them as needed. A stolen short-lived token is a small window, not a permanent door. Store refresh tokens as carefully as passwords, rotate long-lived API keys on a schedule, and make revocation a single, tested operation.

Record what the customer granted

Keep a permission record for every connection: which customer, which system, which scopes, who approved it and when. That record answers the questions that come up later: “Can the assistant see our billing data?” “Who allowed it to send email?” It also lets you show a customer exactly what you hold, and remove it cleanly when they disconnect.

Give agents an allow-list, not a toolbox

An agent should only be able to call tools you have explicitly registered for it, each with a narrow purpose and validated inputs. “Look up a contact by ID” is a tool. “Run any query” is not.

The checks belong in your code, not in the prompt. The tool itself verifies that the requested record belongs to the current customer and user, whatever the model asked for. A prompt can be manipulated; a permission check in code can’t be talked out of its job.

Separate the read path from the write path

Reading and acting are different risks, so give them different routes. Reads flow within the user’s permissions. Writes, such as sending a message, updating a record or issuing a refund, go through a separate path with its own credentials, stricter validation and, where the action matters, a human confirmation before anything leaves the system. If the read side is compromised, it still can’t change anything.

Audit every access

Log which credential was used, by which agent or job, for which customer, to read or write what, with a correlation ID that ties it to the request that triggered it. Review those logs for access no feature should need. An audit trail turns “we think it’s fine” into “here is exactly what happened”.

None of this slows an AI project down when it is designed in from the first connection. Retrofitting it after launch is what’s slow. Our AI on your data service builds these limits in from day one, and the AI readiness check shows where your current setup stands.