How I'd advise a customer rolling out AI agents on their data
The valuable advisory work isn't break-fix. It's proactive — getting in front of the architecture before the production incident, the audit finding, or the stalled rollout. So this is the memo I'd write for a team three months into putting an AI agent over their real data — a CRM, a warehouse, internal APIs, whatever — when the security team starts asking whether they're doing it right.
It's deliberately two-voiced, because the job is two-voiced: the exec wants to know is it safe and will it scale; the platform team wants to know what do we change on Monday. An architect's real work is mapping cleanly between those.
Where these rollouts actually go wrong
Not in the demo. In the second quarter, when the agent has real tools, the data model has sprawled, and nobody owns the grounding. The risks that bite:
| Risk | Why it bites | What I'd advise |
|---|---|---|
| Over-privileged tools | Agent tools wired to broad permissions / a powerful service identity mutate beyond intent | Least-privilege identity per tool; mark destructive tools and gate them; inventory every tool and its blast radius |
| Data model sprawl | Tables and views duplicated, ungoverned ingestion, identity resolution guessed-at | A named owner for the data model; naming + review for new entities; prefer federating over copying |
| Grounding drift | Retrieval goes stale as the systems change; the agent cites last quarter's reality | A re-index cadence tied to data change; a freshness SLO; treat the corpus as a maintained asset |
| Permission bypass | The agent returns a row or field the asking user can't see | Enforce row/field permissions on tools and generated queries — verify on the way out, don't trust the prompt |
| PII in prompts & logs | Sensitive data flows into context windows and trace logs | Data masking on sensitive tiers; log redaction; a sensitive-data handling rule per source |
| No evals | Quality degrades silently; nobody notices until a user does | A small set of golden conversations + regression scoring before each change |
The pattern across all six: the failure isn't the model, it's ungoverned surface area. That's the architect's lane.
The runbook I'd hand them
Phased, because trying to do it all at once is its own risk.
- Baseline & guardrails. Inventory every tool and the identity it runs as; capture the row/field permissions on the data in scope; turn on confirmation gates for anything destructive. Nothing ships until this exists.
- Data model review. Walk the entities, identity-resolution rules, and ingestion sources. Kill duplicates, name an owner, decide federate vs. copy per source.
- Grounding & tools, tiered. Wire retrieval and tools with least privilege and explicit risk tiers (read / write / destructive). The client should see the tier and gate accordingly.
- Evals & observability. Golden conversations, regression scoring, and trace logging with redaction. Make quality measurable before scaling traffic.
- Scale & a standing review board. Only now open the aperture — with a recurring architecture review as the control that keeps surface area governed as it grows.
The review-board checklist
What I'd actually bring to the table:
- Every tool has a named run-as identity and a risk tier. No exceptions logged as "TODO."
- Destructive tools confirm; the confirmation is rendered by the client, not hand-built.
- Row/field permissions are enforced on the output of any agent-generated query, not assumed from the prompt.
- The data model has an owner and a change process; federation is the default over copying.
- Grounding has a freshness SLO and a re-index trigger.
- There's an eval set, and it ran before this change.
Same architecture, two explanations
To the exec: "The agent only ever acts inside the permissions the user already has, it asks before anything irreversible, and we measure its answers before we widen access. The data stays where it lives. We review the whole thing on a cadence — so it scales without the surface area getting away from us."
To the platform team: "Per-tool run-as identities, tier annotations mapped to client confirmation gates, row/field permissions enforced on generated queries, federated data with an owner, a re-index job on data change, and a golden-conversation eval in CI."
Both sentences describe the same system. The architect's job is to keep them true to each other — and to make the safe path the easy one, so the team takes it without being told to.
(This generalizes a specific engagement I wrote up for Salesforce Agentforce + Data 360, but none of it is Salesforce-specific.)