Where is the data, and what happens to it?

Not “what framework are we using.” Not “are we zero trust.” Not “which compliance checkbox do we need.” Those matter eventually. But they are not where you start.

You start by following the data.

The questions

When I was at RBC working on mobile payments, I learned this the hard way. Every time I was confused about how to approach a security problem (and there were many times), the answer was always the same: stop thinking about the system. Start thinking about the data.

Five questions, in order:

1. What is the data? A primary account number. A user credential. A model weight. A delegation token. Name the thing you are protecting.

2. How sensitive is it? Not everything is crown jewels. A payment card number in the clear is catastrophic. A hashed vendor ID is not. Sensitivity determines how much protection is justified.

3. Who can access it? Not who should. Who actually can. The engineer with SSH access to the database host. The cloud operator with hypervisor privileges. The AI agent with an API key in its environment variables.

4. What makes that access trusted? Authentication is part of this, but it is not the whole picture. An API key proves identity. A signed delegation token proves bounded authority. A hardware attestation report proves the execution environment. Freshness guarantees prove the session is live. The strength of the legitimacy chain determines the strength of the trust boundary.

5. Is it protected when it moves? Data at rest, data in transit, data in use. Most teams cover the first two. The third, data in use, is where confidential computing enters the picture. Most architectures still have gaps here.

That is it. Five questions. Follow them through your system and the architecture reveals itself.

Payments: follow the card number

At RBC, I worked on bringing Android Pay to market using host card emulation. HCE meant the phone did not have a hardware secure element to store the card credential. The easy security answer was: do not ship it.

Instead, we followed the data.

The data was the card credential. In a traditional tap-to-pay flow, the credential lives in a hardware chip on the phone and never leaves it. Without that chip, we needed a different architecture.

We asked the five questions:

• What is the data? A payment token derived from the real card number.
• How sensitive is it? Extremely. But we could limit its blast radius by making tokens session-bound and transaction-limited.
• Who can access it? The phone’s application memory. No secure element meant no hardware isolation.
• What makes that access trusted? Device attestation at the time of provisioning, plus user verification. The token service provider verified the device before issuing credentials. But once the token was in application memory, no further legitimacy check existed until the next refresh.
• Is it protected when it moves? TLS to the token service provider. But the real question was: is it protected while it sits in application memory on the phone? The answer was no, so we had to limit the token’s lifetime and transaction count to shrink the window of exposure.

Following the data told us exactly what we needed to build: session-based tokens with limited transaction counts, periodic refresh, tighter constraints on offline use, and a shorter credential lifetime.

We did not start with a framework. We started with the card number and asked what happens to it at every step.

Confidential computing: follow the data in use

Years later, I moved to confidential computing — first at Fortanix, then at Microsoft on Azure.

The entire field exists because of a gap in the five questions. Most enterprises had solid answers for data at rest (encryption) and data in transit (TLS). But data in use, data being actively processed in memory, was unprotected. A privileged operator, a compromised hypervisor, or a malicious insider could read it.

Trusted execution environments close that gap. TEEs create hardware-isolated memory regions where data can be processed without being visible to the host operating system, the hypervisor, or the cloud operator. Remote attestation lets a relying party verify what code is running inside that boundary before sending sensitive data.

But as the Trail of Bits audit of WhatsApp’s Private Processing showed earlier this month, TEEs do not automatically produce trust. The audit matters because each finding broke a different link in the legitimacy chain:

• What is the data? User messages being processed for AI summarization inside a confidential VM.
• How sensitive is it? End-to-end encrypted messages for billions of users. About as sensitive as it gets.
• Who can access it? In theory, only the code inside the enclave. In practice, the audit found that environment variables loaded after measurement could inject arbitrary code, and unmeasured ACPI tables could expose memory to fake virtual devices — all while attestation still appeared valid.
• What makes that access trusted? Remote attestation: a cryptographic report proving what code is running. But the audit found the firmware’s patch level was trusted via self-reporting rather than AMD’s signed certificate, and attestation reports lacked session freshness, making them replayable.
• Is it protected when it moves? TLS between client and enclave, but without a session-bound nonce in the attestation, a replayed report could redirect data to an impersonating server.

Follow the data. Even inside a TEE, the questions do not change. The answers just get more technical, and the gaps get more dangerous when you skip a question.

AI agents: follow the authority

This is where the pattern gets most interesting.

In agent systems, the highest-value data is often not information but permission. When an AI agent acts on behalf of a human — submitting a purchase order, renewing a subscription, modifying an IAM policy — the thing flowing through the system is delegated authority.

The five questions apply directly:

• What is the data? A delegation: “this agent is authorized to act on behalf of this person, within these bounds.”
• How sensitive is it? Very. A compromised or overly broad delegation token is equivalent to a stolen credential, except the agent can act faster and at higher volume than a human.
• Who can access it? The agent runtime, the governance substrate, every MCP tool the agent invokes, and every external API it calls. If the agent holds standing API keys in environment variables, then anything with access to the agent’s process memory has access to the authority.
• What makes that access trusted? Today, most agent systems use API keys or OAuth tokens. That tells you which agent is making the request. It does not tell you who delegated the authority, what scope was granted, whether the delegation is still valid, or whether the execution environment is trustworthy. Authentication without delegation semantics, attestation, and freshness leaves the trust chain incomplete.
• Is it protected when it moves? The delegation flows from human to agent to tool to external system. At each hop, the question is: can the receiving system verify that the authority is legitimate, bounded, and fresh?

This is why attested agent identity matters. This is why delegation needs to be a first-class primitive, not an afterthought. And this is why compliance-grade evidence, structured proof of what happened, who authorized it, and under what policy, is the missing layer.

Follow the authority through the system and the architecture requirements become obvious.

Why this matters more than frameworks

I am not against frameworks. NIST, OWASP, CIS, ISO 27001. They all serve a purpose. They give you coverage checklists and a common language.

But frameworks do not teach you how to think about a new problem. They teach you how to verify that you have covered known categories.

When you encounter something genuinely new, like a payment system without a secure element, an AI model processing encrypted messages inside a TEE, or an autonomous agent authorized to spend money, the framework has not caught up yet. The questions have.

Follow the data is not a framework. It is a discipline. It works because it forces you to trace the asset that carries risk — whether that is information or authority — through every layer of the system, asking at each point: who can see it, what makes that access trusted, and what happens if that trust is misplaced.

Every security architecture I have built, from card tokenization to confidential VMs to agent trust layers, started with that question.

It has held up so far.

Where this gets hard

This model assumes you can name the data and trace it. In sufficiently messy systems (legacy architectures, multi-party AI ecosystems, indirect flows through shared services) that is harder than it sounds. Sensitivity classification is partly art; two reasonable people can disagree on blast radius.

But the value is in forcing the conversation, not in guaranteeing perfect agreement. The messier the system, the harder this exercise is, and the more it matters.

How to apply this

1. Pick a critical data asset — a credential, a token, a delegation, PII.
2. Trace its journey through your system, hop by hop.
3. Ask the five questions at each step. Write down the answers. Highlight where the answers are uncertain — that is where the gaps are.
4. Identify where boundaries are weak — where access is broader than it should be, where trust is weaker than the sensitivity demands, where data is exposed in use.
5. Repeat for every major flow. Make it muscle memory.

If you are getting started with security architecture — or if you are a product manager or engineer who works with security teams — this is the one mental model I would recommend internalizing first. Frameworks come second. The data comes first.

Disclaimer: The views expressed here are my own and do not represent those of my employer.