LLM Council Run

• Generated: 2026-04-22 21:37:11
• Provider: azure_foundry
• Algorithm: consensus_only
• Council models: Mistral-Large-3, DeepSeek-R1, grok-4-20-reasoning
• Chairman: gpt-4.1

Prompt

title: “Follow the Data: The One Question That Makes Security Architecture Simple” slug: “follow-the-data” date: 2026-04-22T21:30:00.000Z draft: true tags: [“Security Architecture”, “InfoSec”, “Confidential Computing”, “AI Security”, “Payments”]

Every security architecture problem I have ever worked on — payments, confidential computing, AI agents — has come down to the same question:

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. How did they authenticate? An API key is not the same as a hardware-attested identity. A session cookie is not the same as a signed delegation token. The strength of the authentication 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, and where most architectures still have gaps.

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.
• How did they authenticate? Device attestation plus user verification at the time of provisioning.
• 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?

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 to reduce the window of exposure.

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 questions still apply:

• What is the data? User messages being processed for AI summarization.
• Who can access it? In theory, only the code inside the enclave. In practice, environment variables loaded after measurement, unmeasured ACPI tables, and self-reported firmware versions all created gaps.
• Is it protected when it moves? The attestation was not bound to individual sessions, so a replayed attestation 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.

AI agents: follow the authority

This is where the pattern gets interesting.

In an agentic system, the “data” you need to follow is not just information. It is authority. 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 power.

The five questions apply directly:

1. What is the data? A delegation: “this agent is authorized to act on behalf of this person, within these bounds.”

2. 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.

3. 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.

4. How did they authenticate? 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, or whether the execution environment is trustworthy.

5. 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 — a payment system without a secure element, an AI model processing encrypted messages inside a TEE, 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 thing you are protecting through every layer of the system, asking at each point: who can see it, who authorized that access, 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 not failed me yet.

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.

Stage 1 - First Opinions

1. Mistral-Large-3

This is a fantastic piece—clear, practical, and deeply insightful. It distills years of security architecture experience into a simple but powerful framework that works across domains (payments, confidential computing, AI agents). Below are some suggestions to refine it further, along with a few structural tweaks to maximize impact.

Strengths to Preserve

1. The Core Insight: The “follow the data” mantra is brilliant. It’s a unifying thread that cuts through buzzwords (Zero Trust, frameworks) and gets to the heart of security: what are you protecting, and where does it go?
2. Real-World Examples: The RBC payments and confidential computing case studies make the abstract concrete. The AI agents section is especially timely and forward-looking.
3. Tone: Conversational but authoritative—like a mentor explaining a hard-won lesson. The “five questions” list is a perfect TL;DR for readers to bookmark.

Suggested Improvements

1. Sharpen the Hook

The intro is strong, but the first paragraph could be punchier. Consider:

*“Every security architecture problem I’ve solved—from mobile payments to AI agents—boils down to one question: Where is the data, and what happens to it?

Not ‘What’s our Zero Trust strategy?’ Not ‘Are we SOC 2 compliant?’ Those matter, but they’re afterthoughts. The real work starts with tracing the data’s journey.”*

Why?

• Leads with the thesis immediately.
• Contrasts the “follow the data” approach with the distractions (frameworks, compliance) that often derail teams.

2. Tighten the Five Questions

The questions are gold, but they could be more scannable. Try formatting them as a checklist with brief explanations:

The Five Questions to Follow the Data

1. What is the data? Name the asset: a card number, model weight, or delegation token.
2. How sensitive is it? Not all data is crown jewels. A hashed ID ≠ a raw PAN.
3. Who can access it? Not who should—who actually can (e.g., the cloud admin, the agent runtime).
4. How did they authenticate? API key ≠ hardware-attested identity. Weak auth = weak trust.
5. Is it protected when it moves? Data at rest? Check. In transit? Check. In use? Most teams miss this.

Why?

• Easier to reference later.
• Reinforces that these are sequential questions (e.g., you can’t answer #3 without #1).

3. Deepen the AI Agents Section

The AI agents part is the most novel and could use more emphasis. Consider:

• Add a concrete example: Show how a delegation token flows through an agentic system (e.g., human → agent → API → external service) and where trust breaks down.
• Highlight the “authority” framing: This is a fresh take. Contrast it with traditional data-centric security (e.g., “In payments, we follow the card number. In AI, we follow the authority to act.”).
• Call out the gap: Most agent systems today treat delegation as an afterthought (e.g., API keys in env vars). What would a “first-class delegation primitive” look like? (e.g., short-lived tokens, hardware-backed attestation, policy-bound scopes).

4. Add a “How to Apply This” Section

Readers will ask: “This is great, but how do I use it tomorrow?” Add a short section with actionable steps:

How to Apply This Today

1. Map a data flow: Pick one critical data asset (e.g., a customer’s PII, an API key). Trace its journey through your system, answering the five questions at each step.
2. Find the gaps: Where does the data leave a protected boundary? Who can access it without strong authentication? Is it encrypted in use?
3. Prioritize fixes: Not all gaps are equal. Focus on the ones where the data is most sensitive or the trust boundary is weakest.
4. Repeat: Do this for every new feature or system. Over time, it becomes muscle memory.

Why?

• Turns theory into practice.
• Encourages readers to try it immediately.

5. Trim Redundancy

• The disclaimer at the end is fine, but the “If you are getting started…” paragraph feels tacked on. Either:
  • Move it to the intro (e.g., “If you’re new to security architecture, this is the one mental model to internalize first.”), or
  • Expand it into a short “Key Takeaways” section.

6. Suggested Title Tweaks

The current title is good, but consider:

• “Follow the Data: The One Question That Cuts Through Security Noise” (More emphasis on the “noise” contrast.)
• “Security Architecture Starts Here: Follow the Data” (More direct for practitioners.)

Final Thought: The “Why This Works” Insight

The piece is compelling because it’s anti-dogma. It doesn’t preach Zero Trust or frameworks—it says, “Forget the hype. Start with the data.” That’s refreshing.

To drive this home, consider adding a short paragraph on why this approach works so well:

“Frameworks like Zero Trust or NIST are useful, but they’re solutions to problems you haven’t defined yet. Following the data forces you to define the problem first. It’s the difference between painting by numbers and drawing from life.”

Summary of Edits

This piece has the potential to become a go-to reference for security practitioners. With these refinements, it’ll be even more impactful. Well done!

2. DeepSeek-R1

Applying “Follow the Data” to Secure a Healthcare Application

To secure a healthcare application handling patient records, we apply the article’s five questions systematically, focusing on data flow and trust boundaries.

1. What is the data?

• Primary Data: Patient records (names, medical histories, diagnoses, treatment plans).
• Secondary Data: API keys, access tokens, audit logs, and metadata (e.g., timestamps of access).

2. How sensitive is it?

• High Sensitivity: Patient records are protected under HIPAA. Unauthorized access could lead to identity theft, discrimination, or legal penalties.
• Moderate Sensitivity: Audit logs (if anonymized) and metadata may have lower sensitivity but still require protection.

3. Who can access it?

• Authorized Users: Doctors, nurses, administrative staff.
• Systems: EHR databases, third-party analytics services, backup systems, AI models for diagnostics.
• Adversaries: Malicious insiders (e.g., disgruntled employees), external attackers, compromised third-party vendors.

4. How did they authenticate?

• Users: Multi-factor authentication (MFA) via SSO (e.g., Okta) or biometrics.
• Systems: API keys for microservices, mutual TLS for internal communication, OAuth tokens for third-party integrations.
• Gaps: Legacy systems using basic auth, shared credentials for backups.

5. Is it protected when it moves?

• At Rest: AES-256 encryption for databases and backups.
• In Transit: TLS 1.3 for web traffic, VPNs for internal networks.
• In Use: Unprotected in application memory during processing (e.g., analytics or AI inference).

Security Architecture Insights

Third-Party Analytics Service

• Data Flow: Patient records are sent to a cloud-based analytics tool.
• Follow the Data:
  1. Sensitivity: High. Data is pseudonymized but still linkable.
  2. Access: Analytics provider’s with admin access to their cloud environment.
  3. Authentication: Static API key stored in the healthcare app’s environment variables.
  4. Protection: TLS in transit, but data decrypted in the provider’s memory.
• Action: Replace API keys with short-lived, scoped OAuth tokens. Require confidential computing for the analytics service to protect data in use.

AI Diagnostic Model

• Data Flow: Patient imaging data (X-rays) sent to an AI model hosted in a public cloud.
• Follow the Data:
  1. Sensitivity: Critical. Leaked imaging data could reveal patient conditions.
  2. Access: Cloud provider’s operators with hypervisor access.
  3. Authentication: Model endpoint uses API keys; no attestation of the runtime environment.
  4. Protection: Data decrypted during model inference.
• Action: Deploy the model in a TEE (e.g., Azure Confidential Compute) with remote attestation to ensure data is processed only in a verified enclave.

Legacy System for Billing

• Data Flow: Billing system (on-premises) accesses patient IDs and insurance details.
• Follow the Data:
  1. Sensitivity: High. Insurance details include personal/financial data.
  2. Access: Legacy system uses shared credentials stored in a plaintext config file.
  3. Authentication: Basic auth over HTTP (no encryption).
  4. Protection: Data exposed in transit and at rest (unencrypted database).
• Action: Wrap the legacy system with an API gateway enforcing mutual TLS and token-based auth. Migrate data to an encrypted store.

Outcome

By following the data, the security team:

• Prioritized protecting patient records in AI/analytics workflows using confidential computing.
• Eliminated shared credentials in legacy systems by introducing modern auth proxies.
• Reduced third-party risk by enforcing scoped tokens and runtime attestation.

Key Takeaway: Instead of starting with HIPAA checklists, mapping data flows and applying the five questions exposed hidden risks (e.g., legacy system gaps, third-party memory access) that frameworks alone would miss. This approach aligns with the article’s thesis: frameworks validate coverage, but following the data reveals what truly needs protection.

3. grok-4-20-reasoning

This is excellent.

The post is sharp, practical, and genuinely useful — which is rare in security architecture writing. The core insight (“follow the data”) is both simple and profound, and the way you trace it through three very different domains (payments, confidential computing, AI agents) gives it real weight.

What works particularly well:

• The five questions are exactly right. They’re in the correct order and at the right level of abstraction.
• The evolution from “follow the data” → “follow the authority” in the AI section is the strongest part. This is a genuine insight that most people in the agent space haven’t internalized yet.
• The RBC Android Pay example is concrete and credible. It shows you actually did the work instead of theorizing.
• The Trail of Bits/WhatsApp reference grounds the confidential computing section in reality instead of marketing fluff.
• The anti-framework stance is refreshing and correct. Frameworks are for verification, not discovery.

Minor suggestions:

1. Title tweak The current title says “The One Question” but you actually present five. This creates a tiny cognitive dissonance.

Consider:

• “Follow the Data: Five Questions That Simplify Security Architecture”
• “Follow the Data” (with the current subtitle as the actual title)
• “The Only Question That Matters in Security Architecture”

2. Small structural refinement

After listing the five questions, you could add one clarifying line:

These aren’t a checklist. They’re a lens. Ask them in order, and the architecture reveals itself.

3. One potential addition (optional)

In the AI agents section, you could add a sixth line that many people miss:

6. When does it expire? (and can it be revoked?)

Delegation without strong revocation semantics is one of the biggest risks in agentic systems. You hint at this with “fresh” in question 5, but making it explicit might be worth it.

Final verdict:

This is publish-ready. The only real question is whether you want it to be “very good” or “exceptionally sharp.”

Would you like me to give you a lightly edited version incorporating the above, or do you prefer to keep it exactly as written? I can also suggest a few punchier lines if you want to increase its impact on LinkedIn/Twitter.

This is the kind of post that should be required reading for anyone doing security architecture on new technology. You nailed it.

Stage 2 - Peer Review Rankings

Stage2 skipped by algorithm.

Stage 3 - Chairman Synthesis

Final Synthesized Answer:

Follow the Data: The Five Questions That Make Security Architecture Simple

Every security architecture problem—whether in payments, confidential computing, or AI—ultimately comes down to one fundamental discipline:

Follow the data.

Not “What framework should we use?” Not “Are we Zero Trust?” Not “What compliance checkbox do we need to tick?” These frameworks and standards are useful, but they come after the real work. The real work starts with tracing the journey of the data—the asset you are actually protecting—through your entire system.

The Five Essential Questions

When faced with a new security challenge, apply these five questions in sequence:

1. What is the data?
   Name it explicitly: card number, user credential, model weight, delegation token, PII… You must know what you’re protecting.

2. How sensitive is it?
   Not all data is equally critical. Sensitivity dictates how much protection is justified—leaked card numbers are catastrophic, hashed vendor IDs much less so.

3. Who can access it?
   Don’t ask who should, ask who actually can: engineers with SSH access, cloud operators, API agents, privileged insiders.

4. How did they authenticate?
   The strength of authentication defines trust boundaries. An API key is not the same as hardware-backed identity, session cookie, or signed delegation token.

5. Is it protected when it moves?
   Cover all phases: data at rest, in transit, and—crucially—in use. Most architectures securely encrypt at rest and transit, but data in use (in memory, inside the app or enclave) is often overlooked.

Ask these questions about every data flow in your system—at each hop, in each environment. The architecture will reveal its strengths and gaps.

Real-World Applications

• Payments:
  At RBC, launching mobile payments without a secure hardware chip forced us to trace the card credential at every step. We reduced risk not just by encrypting data, but by limiting lifetime, transaction count, and exposure window—because we followed the data.

• Confidential Computing:
  In cloud environments, encryption at rest and transit can’t protect against memory scraping by privileged insiders or compromised hypervisors. Trusted Execution Environments (TEEs) help, but only if you rigorously follow the data—even within the enclave. Recent audits (e.g., WhatsApp Private Processing) show gaps remain unless you ask all five questions.

• AI Agents:
  Security isn’t just about information—it’s about authority. Delegations (what the agent is permitted to do) are “data” too, and must be tracked. Who gave the agent power? How is it scoped, authenticated, revocable? In agentic systems, following authority as data exposes risks that frameworks miss.

Why “Follow the Data” Trumps Frameworks

Frameworks like NIST, OWASP, or Zero Trust are excellent for coverage: they make sure you don’t forget known categories, and help with compliance. But they don’t teach you how to think about genuinely new problems. They help you verify solutions, not define the problem.

When a new threat or technology emerges—a payment system without hardware, an AI processing encrypted messages, an autonomous agent acting on delegated authority—the frameworks aren’t ready yet. The questions are.

“Follow the data” is not a checklist—it’s a lens. It forces you to look at your system from the asset’s perspective, step by step, exposing gaps frameworks won’t catch.

How to Apply This in Practice

1. Pick a critical data asset (a credential, a token, PII).
2. Trace its journey through your system, asking the five questions at each step.
3. Identify where boundaries are weak (who has access, where data is exposed in use).
4. Prioritize fixes—focus on the most sensitive data and riskiest boundaries.
5. Repeat for every major feature or flow. Make it muscle memory.

Key Takeaways

• Start with data—not frameworks.
• Apply these five questions rigorously—don’t skip steps.
• Use frameworks for coverage, but following the data uncovers true risks, especially in novel systems.

If you’re new to security architecture, internalize this mental model first. Frameworks come second; tracing the data comes first. It’s the discipline that never fails.

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

Metadata

{
  "algorithm": "consensus_only",
  "label_to_model": {},
  "aggregate_rankings": []
}