How FDE Teams Should Coordinate with Internal IT and Security: Responsibility Boundaries to Establish Before Deployment

Last year, we had a manufacturing client with an FDE team scheduled to kick off on Monday. The technical solution was locked down, the PoC had run successfully, and the equipment list was finalized. That Monday rolled around, and four of us sat in a conference room waiting the entire day; security hadn't approved the access credentials yet. Not because they were being difficult. It was because from start to finish, nobody had ever talked to security about which systems these outside engineers could access and to what extent.

This pattern shows up repeatedly. When enterprises deploy AI, model selection rarely becomes the limiting factor. What actually slows things down is FDE teams, IT, and security operating without agreement on access, data handling, and ownership after launch. The solution requires getting these conversations right upfront.

FDE deployment is about external engineers accessing production systems

FDE (Forward-Deployed Engineering) collaboration with internal IT and security refers to how three parties, external engineers, internal IT, and security, define task allocation and responsibility boundaries around access permissions, data compliance, and operational handoff when deploying AI to production.

The phrase 'production environment' matters here. During demo phases, everyone operates cautiously because the environment is isolated, data is fake, and nobody faces real consequences. Once you go live, FDE needs access to real databases, real API keys, and real employee account systems, that's when IT and security take the conversation seriously. Postponing these discussions until your team arrives guarantees that earlier timelines become impossible to meet.

Access, data, and handoff: what to discuss before deployment

Access permissions. Request only what's needed, not admin access. Before we arrive, we submit a detailed access request: which systems need read or write access, the minimum scope required, account expiration dates, and how credentials get revoked once we leave. We use temporary accounts, bind them to SSO, and set up a dedicated VPN tunnel rather than share passwords that let us blend into the infrastructure. IT isn't afraid to grant permissions. They're afraid of not knowing what you took, and not being able to get it back afterward.

Data compliance. Finance and healthcare clients pay attention to this. Which data can leave the internal network? What can only be processed locally? Will model training or RAG indexing pull personally identifiable information into a vector database? Document the answers and get security's approval before proceeding. We learned this through experience: a team once fed work orders containing customer names into a test index. Though on an internal network, it triggered security's compliance monitoring and pushed the timeline back two weeks. From that point on, data classification and de-identification became required parts of the onboarding document.

Operational handoff. Who runs the system after launch? Most teams skip this conversation, and it creates the most friction. FDE's role is getting a system to production and into users' hands, not staying indefinitely. What do we deliver? What does your IT team take over? How do SLAs work? How do we transfer code and documentation? Work through this carefully; if you don't, you'll encounter blame-shifting later.

Responsibility matrix

Before deployment, work through this matrix with your IT and security teams. Every cell gets assigned: who leads, who supports, who approves. Leave nothing blank:

It looks bureaucratic, but it eliminates deployment friction by converting abstract concerns into an agreement both sides sign. Once IT and security understand what you need, where boundaries lie, and how things conclude, they move from defense to collaboration.

Security as a teammate, not a checkpoint

Mindset matters. Many external teams treat security as an obstacle to work around. It works better to involve the security lead in week one as a collaborator in designing the permission model, not just as an observer receiving briefings. Once he's reviewed your approach, he'll work to help you succeed.

When we deploy FDE teams at Tenten, we spend the first one or two weeks on this before writing any production code: establishing permissions, data compliance, and operational boundaries with your IT and security teams. The time investment pays off by preventing deployment delays later. A system that launches and gets handed off to daily operators matters more than how good it looks during demos.