secure system: what an AI agent is allowed to see in the business data

secure system is what this article is about, even when the technical tool has another name. For a restaurant the day looks like this: table bookings on WhatsApp, a menu that changes by word of mouth, and deliveries with whoever answered first. Each person sees what they need, and not the rest. That includes the agent and the bot. We define roles, keep passwords out of WhatsApp, and check who signed in. The information system, the AI agent and the WhatsApp bot share permissions. A connection without permission is a hole, not a feature. Access comes off the day someone leaves. It does not stay because somebody forgot. We do not put the whole business with one vendor without knowing where the keys are. The rest of the article is how a software house builds that without leaving the team with a demo.

Connecting AI to business data multiplies leverage: support gets grounded answers, analysts draft faster, and operations triage messy inputs. It also multiplies data egress paths-every prompt can become an accidental export if architects sleepwalk.

Data minimization is the first control: send the smallest snippet that answers the task, strip boilerplate headers, and prefer aggregates or pseudonyms over raw identifiers. Ask whether the model needs the full document or only two salient paragraphs.

Authorization must wrap retrieval, not trust the model to refuse politely. Fetch records only after verifying tenant, role, and object-level permissions. Log access alongside model calls for investigations.

Logging balances debuggability with leakage risk. Redact card numbers, government IDs, and auth tokens; cap retention on prompt logs; restrict observability RBAC. Third-party model endpoints belong in your data-inventory and vendor-risk reviews.

Prompt injection belongs in threat models even for internal tools: attackers or misguided users embed instructions inside tickets, PDFs, or web pages loaded into context. Mitigate with structural separators, allowlisted tools, and validation of any action derived from model output.

Regulatory overlap is increasingly the norm in many jurisdictions: privacy law governs personal data processing while AI-specific frameworks may impose additional transparency, risk management, and documentation expectations for certain high-impact systems. Map your features with legal counsel rather than assuming “internal only” exempts review.

Contracts and DPAs should reflect subprocessors, cross-border transfers, which features route data to which regions, and provider settings that affect logging, retention, or training use of customer content. Ambiguity here becomes courtroom ambiguity later.

Employee training is short and concrete: no secrets in chat, no unapproved uploads of customer exports, escalate weird model behavior. Culture beats forty-page policies nobody opens.

Incident response extends to AI keys and integrations: revoke, rotate, assess scope, notify customers if their data was exfiltrated via misconfiguration. Practice the drill-muscle memory decays.

In summary: treat AI features as regulated data processing with clever UX-minimize payloads, enforce auth before retrieval, manage logs and vendors deliberately, and pair technical controls with legal clarity. Trust arrives from systems that assume mistakes will happen and contain them.

You can come back from here to a plain conversation: Bring who can see customers, money and documents today, even if the answer is “everyone, that is how it ended up”. You can open the system in the morning without fearing that someone took the keys home. AI agents, an information system and a WhatsApp bot stay the same offer, with human approval, from an official Meta provider.