Aona FDSE service
What is a forward deployed security engineer?
Aona tests employee AI access and data controls, then gives your team clear findings.
- 01ScopeWho can reach which data?
- 02ConfigureWhich controls are needed?
- 03VerifyDo they work as intended?
What the leading teams actually do.
Palantir’s practitioner account describes an FDSE who combines existing platform capabilities for a particular customer, writes and reviews code, configures access controls and maintains production systems. Lessons from the deployment feed back into the product. Security already appears in that delivery work. Read the Palantir account.
Atlassian’s US AI FDE leader, Paavany Jayanty, describes starting with the customer’s business goal, choosing a small number of use cases and building in their environment. The feedback loop to product teams is part of the model. Read her explanation.
For a buyer, that suggests a useful test: can this person turn a requirement into a working change, explain its trade-offs and leave your team able to operate it?
The security title covers different mandates.
OpenAI’s FDSecE role embeds with strategic public-sector customers from design through ongoing operations. Its remit includes authentication, access controls, encryption, network and system security, plus continued monitoring and validation. It is a substantial infrastructure security role.
Palantir’s government security role emphasises the Authorization to Operate process: converting government requirements into technical work and producing evidence such as system security plans and architecture diagrams.
These are provider-specific mandates. An employee AI rollout needs its own scope: which accounts, tools, data paths and security decisions the engineer will actually cover. Hiring the title does not define the engagement.
Illustrative employee rollout
A useful answer can reveal the wrong access.
A sales team pilots an AI assistant connected to an internal document collection. It produces an accurate account brief, including a confidential pricing file that a sales employee should not have.
The security engineer traces the result to an over-broad source group, agrees the intended access with the data owner and works with the administrator to narrow it. The team then tests both sides of the boundary: the employee should lose access; the authorised pricing manager should retain it.
The handoff includes the cause, approved change and retest evidence. A refusal in one conversation alone would not prove the access boundary had been corrected.
Can the right people reach the right data?
- Expected
- Sales can use account notes. Restricted pricing stays with the pricing team.
- Check
- Use separate sales and pricing test accounts. Record source access and assistant results against the same synthetic file.
- Retest
- Repeat after the permission change has propagated. Keep the configuration, time and account role with each result.
Inside Aona’s FDSE service
Make the work repeatable.
We scope the review around three boundaries: what the assistant can retrieve, what employees can submit, and what administrators can observe and change. Connected search, a pasted prompt and a file upload need separate checks.
- 01Map the exact route. Name the account type, employee role, AI surface and data source. A managed browser result says little about an untested desktop app or personal account.
- 02Make each check reproducible. Keep the synthetic input, expected outcome, actual result, policy version and relevant log. Record untested paths explicitly.
- 03Leave an operating handoff. Name the owner of each finding, the retest steps and the changes that trigger another review, such as a new connector, user group or input path.
Success means the customer can repeat the check after the engineer leaves. That is more useful than a one-off green status with no account, configuration or test history behind it.
Embedding does not establish independence.
A vendor’s FDSecE can provide deep platform expertise while remaining part of that vendor’s delivery team. Independence depends on who sets the review scope, can challenge a proposed launch and receives unresolved findings.
Our view is to give security a defined workstream alongside implementation, with evidence available to the customer’s decision owner. Aona reviewing its own controls would not be an independent audit of Aona. See how to assign delivery, review and launch decisions.