Data Security for Humans, Applications, and Agents

Chapter 12 of Data Architect, Part 2: Architecting at Scale. Previous: Transactions, Concurrency, and Reliability.

Security architecture doesn’t start with a permission set or a sharing rule. It starts earlier, with the data model: which object holds a field, whether a child inherits its parent’s access, what’s classified as sensitive, and which consumers can reach it. By the time someone opens Setup, most of the security outcome has already been decided.

Image generated with AI.

This chapter is about designing those boundaries on purpose, for three kinds of consumers: people, applications, and now agents. Then it closes Part 2 by putting every Part 2 chapter together on one scenario.

One example runs through all five modules: Steve Trucking’s delivery, and the gate code on it. A crew needs that code on the day of the stop. A Retail Partner’s DC manager needs the partner’s own deliveries and must never see another partner’s. An integration needs the status, nothing else. And soon an agent answers the Recipient’s “where’s my delivery?” Same record, very different needs.

The ideas in this chapter

• Security is decided in the data model. Structure decides what can be isolated before any access is configured.
• Hiding a field isn’t securing it. A page layout hides; field-level security secures, everywhere the field can travel.
• Split the data when the security differs. A coherent group with a different audience belongs on its own record.
• Relationships are security architecture. Master-detail inherits access; a lookup child keeps its own.
• Start private if even one person mustn’t see it, then open up with the role hierarchy, groups and sharing rules.
• When a sharing rule is one of a series, ask what the series will look like at year five. Fifty criteria-based rules go fast.
• Classification without enforcement is decoration. A label isn’t a lock; the protection matrix turns each level into decisions.
• Probabilistic by default; deterministic only where exact-match filtering is essential. Choose the encryption by the field’s use.
• Minimization is a security control too. The best sensitive data is data you don’t have.
• Protect the value, or protect the capability. Give a consumer the answer when the answer is all it needs.
• Treat an agent like a curious human: give it only what it needs to do its job, and design what it may know separately from what it may do.
• A prompt is not a permission set. Approvals belong in the workflow; every prompt is a dangerous surface, like SQL injection.
• Discover, derive, infer, act. Try to break the agent before go-live.

The path through this chapter

Five modules, each standing on its own.

1. Security Is Decided in the Data Model. Who sees the gate code; three kinds of consumers; structural and record-level security; why hiding a field isn’t securing it; the controlled door; splitting the data; relationships as security architecture; applications and agents get their own boundaries.
2. The Sharing Model Your Data Model Must Respect. Org-wide defaults; parents decide for their children; the role hierarchy as a security decision; groups and sharing rules, counted to year five; restriction rules and their limits; external users and their licenses; prove it with three users.
3. Classify, Then Protect. Sensitivity and use; how many levels; the protection matrix, with columns for applications, agents and AI prompts; which levels get encryption, and which kind; masking; minimization and the regulations behind it; value or capability.
4. Treat an Agent Like a Curious Human. Three agents at Steve Trucking; start with the job; who the agent runs as; know and do; capabilities, not raw power; approvals in a Flow checkpoint; every prompt treated like SQL injection; side doors and aggregation; now try to break it.
5. Checkpoint 2: Steve Trucking at Scale, What I Would Architect. Try the challenge first. Then the Part 2 design: year five, a 13-month window and one archive, the hot spots, the nine contracts and who proves each, RouteDesk retired, and who sees what, from sharing sets for DC managers to a gate code that appears and disappears.

What an architect decides here

• Which structure each security boundary rests on: the object, the relationship, the field.
• The baseline and how it opens: org-wide defaults, the role hierarchy, groups and rules, counted against the limits at year five.
• Which licenses external users need, and which sharing tools each license brings.
• How each classification level is protected: access, encryption, masking, retention, and what applications, agents and prompts may see.
• Each agent’s job, who it runs as, what it may know and do, and where its approvals live.
• How the boundaries are proved before go-live, by people who try to break them.

Beyond the exam: agents are a third kind of consumer, and they push on every gap a person would leave alone. The platform’s security model doesn’t change; the number of paths an agent will try does. Design the boundary for the most curious consumer, and test it as one.

Explore

• Salesforce Help: Sharing Rules (opens in a new tab) and Create a Sharing Set for Experience Cloud Site Users (opens in a new tab), checked 2026-11-01.
• Salesforce Help: Agent Execution Context and Data Access by Type (opens in a new tab), checked 2026-11-01.
• Salesforce Well-Architected: Trust for the Agentic Enterprise (opens in a new tab), checked 2026-11-01.
• OWASP GenAI Security Project: LLM01:2025 Prompt Injection (opens in a new tab), checked 2026-11-01.
• Each module’s Explore section has its full, dated source list.

Next: Beyond Relational: Data Structures for Analytics and AI (coming soon)