Security Posture in the Discovery Phase: What the FDE Has to Surface Early
By Pralhad7 MIN READ
You're the FDE running discovery, and it's tempting to treat security as someone else's stage - a procurement gate that happens later, after you've nailed the use case and proven the value. Resist that. On an AI-native platform, the customer's security posture isn't a downstream checkbox. It's a discovery input that shapes the entire solution, and if you find out about it late, it doesn't just slow the deal - it can invalidate the architecture you already designed.
Here's the thing that makes AI-native different: your platform almost certainly moves the customer's data somewhere it's never gone before - into models, through pipelines, sometimes across a third-party provider's boundary. That's a new and unfamiliar risk surface, and the customer's security team knows it. So the questions you ask about security in discovery aren't a compliance formality. They're how you find the landmines while there's still time to route around them.
This is what to surface, and how.
Why security belongs in discovery, not after it
If you defer security, you build a beautiful proof of concept and then watch it die in a security review nobody scoped. The CISO asks where the data goes, the answer turns out to be unacceptable, and now you're re-architecting under deadline pressure with a champion who's lost momentum.
Surfacing posture early does the opposite. It lets architecture and procurement move in parallel instead of in sequence. It tells you which version of your platform the customer can even run before you demo the wrong one. And - this matters more than teams admit - proactively raising security builds trust. Every enterprise evaluating AI in 2026 is nervous about it; the vendor who brings up data handling before being asked reads as the safe choice, not the risky one.
So treat the security thread as a core part of discovery, running alongside the use-case conversation from day one.
Important Areas to Surface
01. Start with the data: sensitivity, residency, flow, and training
Everything in an AI-native deployment traces back to data, so this is where discovery starts.
Data classification and sensitivity:
Find out exactly what data will flow through the platform, and how sensitive it is. Is it PII, PHI, financial records, regulated data, or the customer's crown-jewel IP? The answer sets the ceiling on everything else - the more sensitive the data, the more constrained your deployment options. Ask this first, because a platform handling health records and one handling public marketing copy are, from a security standpoint, two different products.
Data residency and sovereignty:
Establish where data is legally and contractually allowed to live and be processed. Regulations may forbid it leaving a region or country entirely. If your default deployment processes data in the wrong geography, you need to know in discovery, not in the security review.
Data flow - and where the model actually runs:
This is the defining AI-native question. Does the customer's data leave their trust boundary to reach the model? If your platform calls a third-party model provider, the customer's data is transiting to that provider, and for many enterprises that alone is a blocker. Discover early whether they can tolerate a hosted model, or whether they need in-VPC, private, or self-hosted inference. The answer determines your entire deployment topology.
Training and retention:
Ask the question the customer is definitely thinking: is our data used to train your models, and how long is it retained? For most enterprises, "your data is never used for training" is a hard requirement, and they'll want it backed by contract and enforced technically, not just promised verbally. Surface their expectation and know what guarantees you can actually make.
02. Access, identity, and isolation
Once you know what the data is, find out who's allowed to touch it and how it's kept apart.
Identity and access control:
Learn their requirements around SSO, single sign-on providers, role-based access, and least-privilege enforcement. Enterprises expect to manage access through their own identity provider and to control precisely who can query the system and see what. If your platform can't meet their identity model, that's a discovery-phase finding.
Tenant isolation:
For a multi-tenant platform, understand how strict their isolation requirement is. Some customers are fine with logical separation; others - especially in regulated industries - will demand dedicated infrastructure or single-tenancy. This shapes both architecture and pricing, so it can't wait.
03. The AI-specific threat surface
This is the part a traditional security discovery would miss, and the part your customer's security team is most uncertain about - which means you should be the one to raise it.
Prompt injection and output exfiltration:
An AI system that reads untrusted input and produces free-form output opens paths that don't exist in conventional software: a crafted input steering the model to do something unintended, or a model output leaking sensitive data it shouldn't have surfaced. You don't need to solve this on the discovery call, but you need to show you understand it and have answers - because a technical buyer who's paying attention will ask.
Agent and tool permissions:
If your platform lets the AI take actions - calling tools, touching systems, executing workflows - discover how much autonomy the customer is comfortable granting and what guardrails they expect. An over-permissioned agent is a security incident waiting to happen, and framing this early signals that you take the "what can it do" question as seriously as "what can it say."
Observability and auditability:
Establish what they need to see: can they get a log of what the AI did, what data it accessed, and ideally why? Regulated customers need to reconstruct and explain AI decisions after the fact. If auditability is a requirement, it's an architectural one, and discovery is when you learn that.
04. Compliance, certifications, and deployment constraints
Certifications as table stakes:
Find out early which certifications and frameworks they require - SOC 2, ISO 27001, HIPAA, FedRAMP, or industry-specific standards. For many enterprises, a missing certification means you can't even run a pilot, so this is a qualifying question, not a nice-to-have. Know what you have and what you don't, and be honest about both.
Deployment topology:
Tie it all together by discovering the deployment model their posture demands: SaaS multi-tenant, single-tenant, private cloud, in-VPC, on-prem, or air-gapped. This is downstream of everything above, and it's the single most important architectural fact to leave discovery with, because getting it wrong means rebuilding.
Find the security stakeholder - and bring them in early
The most important discovery move isn't a question about technology; it's identifying who owns the security decision and when they need to be involved. Somewhere behind your champion is a security or compliance stakeholder - often a CISO - who can veto the whole thing.
Find them early. Ask your champion who signs off on security and how long that review typically takes, then get that clock started in parallel with the technical work. The single most common way an AI deployment stalls is a security review that began too late. You can't prevent the review, but you can make sure it isn't the thing standing between a successful pilot and a dead one.
How to carry the security thread through discovery
A few principles keep this from feeling like an interrogation.
Raise it proactively. Bring up data handling, residency, and training before the customer has to - it builds far more trust than answering defensively when asked.
Be honest about gaps. If you don't have a certification or can't yet support a deployment mode, say so plainly. Every buyer has been burned by an AI vendor who overpromised; the one who's straight about limitations wins on the only axis a demo can't fake - credibility.
Translate for the room. The technical buyer wants to know the mechanics; the CISO wants to know the risk is bounded and governed; the business owner wants to know it won't become a headline. Same posture, three vocabularies - meet each where they are.
Leave discovery with a security picture, not just a use case. By the end, you should be able to state the data sensitivity, the residency constraints, whether data can reach a hosted model, the identity and isolation requirements, the required certifications, the deployment topology, and the name of the person who owns sign-off. That picture is what lets the rest of the engagement move fast.
The bottom line
On an AI-native platform, security posture isn't the stage after discovery - it's woven through discovery itself, because it determines what you can build and how. Surface the data sensitivity, the residency limits, and above all where the model runs relative to the customer's trust boundary.
Name the AI-specific risks before you're asked. Find the security owner and start their clock early. Do that, and security stops being the thing that kills your deployment at the last minute and becomes the thing that earns the trust every AI engagement ultimately depends on.