How Should External FDE Teams Collaborate with Internal IT and Security? Access Controls, Audit Trails, and Data Boundaries

Last year we prepared to deploy a RAG system for a major financial holding company's core systems. In the first meeting, their Chief Security Officer skipped the technical questions and asked three instead: "What accounts will your engineers have access to? Can we trace who did what? Will our customer data leave this building?"

These three questions are the gatekeeping criterion for external FDE teams. If you can't answer them convincingly, you won't get into production, no matter how advanced your technology is. This piece focuses on one thing: how to design an FDE security collaboration framework for access controls, audit trails, and data boundaries that internal IT and security teams can confidently support.

A model built on systems, not trust

An FDE security collaboration model combines contractual agreements and technical controls that allow external engineers to deploy AI systems to customer production while operating under minimum privilege, complete auditability, and zero data residency outside the customer environment.

This kind of model works even if you assume external people can't be trusted. That's not about distrusting your engineers. It's a fundamental security design principle. You can't build controls on personal trust. You have to build them into systems and processes. Mature external teams recognize this and help customers establish this wall, because it protects both sides.

Three pillars: least privilege, audit trail, data boundary

These three questions become three concrete pillars.

Least privilege: External engineers shouldn't have admin accounts, only enough access to ship the sprint. In practice, this means: all access goes through the customer's own identity system (SSO / IdP), with no backdoors; permissions follow roles (RBAC), so external engineers get access only to the designated project repo, vector database namespace, and test dataset; high-risk operations (touching production databases, changing permissions) always use JIT (Just-In-Time) temporary authorization that gets revoked right after use, not standing access. If a single account leaks, the blast radius stays contained to one project.

Audit trail: The answer to "can we trace who did what?" is straightforward. Every access, query, prompt, and model response gets a timestamped, identity-tagged log written to the customer's SIEM or logging platform, not external team systems. The customer owns the logs. External teams can't modify or delete their own traces. We learned this the hard way: on one project, we kept LLM call logs only at the application layer, and when audit time came, records didn't reconcile. Now we require an immutable access record at the API gateway layer. Audit must be real-time data, not a document compiled afterward.

Data boundary: "Will data leave this building?" involves three layers: data residency (whether systems run in the customer VPC or on-premises, or get outsourced to cloud), data transit (whether data flows through external APIs), and whether the model learns customer data. For financial and healthcare projects, our default is that data stays in the customer environment. Model deployment runs inside the customer's VPC, or we use an enterprise-tier API with a data processing agreement and zero-retention clauses. Sensitive fields get de-identified before entering the model. Development and testing always use sanitized data, never production data copied to an engineer's laptop.

One checklist, ready for your security team to review

Guardrails for both sides, not constraints

Many think these controls slow down external teams. They don't. When permission boundaries, audit methods, and data rules are clear from week one, every approval gate that follows moves much faster. The security team doesn't re-evaluate risk each time. They just verify the contract is being followed. What actually slows things is the gray area: "Give me all permissions now, and I promise I'll be careful." That approach leads to endless friction.

There's also a finish line people often overlook: offboarding. On the day the project closes, you revoke accounts, shut down temporary authorizations, and hand back runbooks and architecture docs to the internal team. An external FDE's goal isn't to lock in long-term access; it's to hand the system back stable and operational, so internal IT can run it themselves.

At Tenten, before doing an FDE deployment, we fill out this checklist together with the customer's security team, write it into the collaboration agreement, then start working on the systems. For us, passing security review matters as much as having a polished demo. You can't ship if you're not allowed to ship.