I was halfway through building a spreadsheet. One column for the field, one for the object, one for whether it counted as personal data — the sort of list you make when someone asks the reasonable question, “so what regulated data can this agent actually see?”
I was some way down the list when I stopped, because a thought arrived that I did not enjoy. This spreadsheet was going to be wrong within a month. Every field created after today would be missing from it, every deleted field would linger in it, and its accuracy would depend entirely on me remembering to update a file that lives outside the org.
Then the better thought arrived: the org already knows. Somebody had answered this question, field by field, years before I asked it. I had simply never read the answer back.
The metadata almost nobody reads back
When you create a custom field in Salesforce, its metadata can carry a compliance categorisation — a complianceGroup — alongside a security classification describing how sensitive the data is. The compliance values are the vocabulary you would expect: PII, GDPR, HIPAA, and the rest of that family.
If you have never noticed these, that is the normal experience. They are set in the field’s definition, usually at creation time by the person who understood best what the field was for, and then — in most orgs I have looked at — never consulted again. The label is applied and the label goes quiet.
But it is still there, stored on the field, travelling with the field when it deploys. And, crucially, it is readable: your code and your tooling can ask the org which fields carry which classification and get an answer that was true one second ago.
Your org already holds an answer to “which of my fields are regulated.” Most teams write that answer down once and then maintain a second, worse copy of it in a spreadsheet.
Why the org’s own answer beats a hand-maintained list
Let me be specific about why this matters, because “use the metadata” sounds like tidiness advice and it is not.
It cannot drift the way a document drifts. A spreadsheet describes the org as it was on the day someone last edited the file. The metadata is the org. Create a field this afternoon with a compliance classification, and every reader of that metadata sees it this afternoon.
It is recorded where the decision was made. The person creating the field knew what was going into it. That is the moment when the classification is easiest to get right, and it is the moment the platform asks the question.
It is machine-readable, which changes what you can build on it. A list a human maintains can only be used by humans reading carefully. A label stored in metadata can be read by a check that runs every time — before a release, before an agent goes live, or on a schedule. Anything you can read automatically, you can enforce automatically.
For agents, though, “labelled” is not the same as “reachable”
Here is where this becomes an Agentforce article rather than a metadata one.
Knowing that a field carries a PII classification tells you what the field is. It does not tell you whether your agent can get to it. Those are two different questions, and only the second is a risk. A regulated field nothing can reach is a well-labelled field at rest. A regulated field your agent can pull into a conversation is an exposure.
So the useful question is an intersection: which compliance-labelled fields can this agent’s code actually reach?
You cannot answer that by reading a topic’s instructions, because the instructions are not where the data travels. Data reaches an agent through the code behind its actions, along a path with several hops — each of which is somebody’s file, often somebody else’s file.
The path, hop by hop
This is the anatomy worth memorising, because it is the same nearly every time.
- A SOQL query in the Apex behind an agent action names a field as one of its columns. That is the moment the value enters the code.
- An output variable carries it outwards. In an invocable action, outputs are marked with
@InvocableVariable, the annotation that makes a property visible to the declarative layer — which is to say, visible to the agent. - A prompt template consumes that output and places it into the text the model receives. Once a value is in the prompt, it is in the conversation.
Three hops, and no single file shows all three. The developer reading the Apex cannot see the prompt template. The person editing the prompt template cannot see which SOQL column feeds the variable they are inserting. This is exactly the gap where careful people miss things — not through carelessness, but because the evidence is distributed.
Reading the labels back, automatically
This is the problem I ended up building a tool for, rather than finishing that spreadsheet. It is a static analyzer: it reads code and metadata as text and traces paths, without running anything and without asking a language model for an opinion. It reads the compliance classifications back out of the org’s own field metadata and intersects them with what an agent’s code can actually reach.
On one agent path it did exactly what I had been failing to do by eye. It traced a compliance-labelled field from a SOQL column, through an Apex @InvocableVariable output, into the prompt template — and reported it at line 125. Not “this org contains PII.” A specific field, on a specific path, at a specific line.
That is the difference between a classification and a finding. One tells you a fact about your data model; the other tells you where to look.
The tool is MIT-licensed and open source at github.com/aksumustafa1625/agent-blast-radius if you want to read how the tracing is done. But do not read this as an advertisement, because the idea underneath belongs to nobody: the labels already exist, so read them back. If you build something better than mine, good.
Your next step
Two small tasks, in order.
First, open a handful of custom fields you know hold personal or regulated data and look at their compliance classification. If it is blank, you have found where to start — and filling it in is a short job that permanently improves every automated check you will ever run.
Second, take one agent action you have shipped and trace its path by hand: the SOQL columns in its Apex, then the @InvocableVariable outputs, then the prompt template that consumes them. Ask whether any classified field survives all three hops.
Doing it by hand once teaches you the shape of the problem. After that you will want it checked automatically — and the org has been holding the answer the whole time, waiting for someone to read it back.
If agent actions themselves are still new, start with your first Agentforce action and prompt templates explained. The full series lives in Agentforce.