Workforce AI is our focus.
AI visibility, policy enforcement and sensitive-data protection are the core of Aona’s platform.
Aona FDSE / AI Security Partner
The security
safety net for
AI rollouts.
Forward deployed security engineering alongside your FDE, internal team and delivery partners.
Discuss a pilot See how we work together
During implementation
Security alongside
each delivery step.
Forward deployed engineers (FDEs) scope the use case, connect data, build or configure the solution, then test and launch it with users.
Design
- Delivery
- Choose the use case and pilot users.
- Aona FDSE
- Map data boundaries and agree checks.
- Shared checkpoint
- Scope and acceptance criteria
Configure
- Delivery
- Set roles and existing read-only connector access.
- Aona FDSE
- Review permissions and sensitive-data rules.
- Shared checkpoint
- Configuration ready to test
Validate
- Delivery
- Run the user pilot and apply fixes.
- Aona FDSE
- Test allowed and restricted paths; record evidence.
- Shared checkpoint
- Findings and retest results
Handoff
- Delivery
- Prepare training, support and rollout.
- Aona FDSE
- Report remaining gaps and review triggers.
- Shared checkpoint
- Your launch decision
Working with your team
One finding.
The right people.
Internal teams and external partners own secure delivery. Aona adds focused verification for your security and compliance owners.
Agree
Your security and compliance owners set criteria.
Fix
Your implementation team and administrator share settings and resolve gaps.
Verify
Aona tests, records evidence and reports to your security owner.
Decide
Your owners accept or reject remaining gaps and set retest conditions.
An unintended role can retrieve restricted data.
- Fix owner
- Administrator and implementation partner
- Evidence
- Test accounts, permissions, query and observed output
- Retest criteria
- Restricted account denied.
Intended account still works.
AcceptanceCustomer security owner, with compliance input.
Your security safety net
Find it. Assign it.
Verify the fix.
Aona keeps security questions visible as delivery moves forward, with evidence and an owner for each next action.
See the checks in practiceMissing evidence?
Keep it unverified.
A configured setting needs an observed result before the check is recorded as passed.
A control fails?
Assign a fix and retest.
The delivery or IT owner makes the change. Aona repeats the agreed check and updates the record.
A risk remains at launch?
Escalate the decision.
Recommend a restriction or hold when criteria are unmet. Your security owner reviews the remaining risk.
Security & access
Follow the data.
Check each boundary.
We review the configuration your employees will actually use.
EmployeeWork account · assigned role
AI workspaceAllowed app · connector permissions
Company dataSource permissions · selected collection
One broad permission can change who sees the result.
- Identity & permissions
- Review work accounts, workspace roles and source access. Compare intended access with effective access.
- Sensitive prompts & files
- Use synthetic data to test agreed blocking or redaction rules, plus an allowed example that should still work.
- Connected information
- Check retrieval with authorised and restricted accounts. Recheck after an agreed permission change.
- Logs & response
- Verify what the available logs record, who can see them and who acts on a finding.
Selected within the pilot’s 12 agreed checks, on the scoped platform, browser and operating system.
Privacy & procurement
Where does
the data go?
Separate provider commitments, tenant settings and what can be verified.
Data-handling reviewQuestions to resolve
- Training
- How may prompts, files and outputs be used under your chosen plan?
- Retention
- What remains in chats, synced indexes and logs? Who controls deletion?
- Location
- Where is data stored and processed, including connected providers?
Document the source, setting and unanswered question for your privacy or procurement owner.
Control verification
See what we
actually test.
Aona / Verification recordIllustrative scenarios
01
Can the wrong role retrieve it?
A synthetic HR record in the agreed collection. One HR account and one sales account.
- Test
- Ask both accounts to retrieve the same record.
- Expect
- HR can retrieve it. Sales cannot.
- If it fails
- Trace source and connector permissions. Your administrator corrects access; Aona retests.
Verification record
Account roles, source permissions, prompts, outputs and timestamps.
02
Does the data rule work?
A synthetic customer record and a harmless control example on the agreed browser and OS.
- Test
- Submit both through the selected prompt or file path.
- Expect
- The sensitive sample follows the agreed block or redaction rule. The harmless sample remains usable.
- If it fails
- Identify the uncovered path or configuration gap and assign the fix.
Verification record
Policy version, input path, expected action and observed result.
03
Does access really end?
An account that could previously retrieve the synthetic test record.
- Test
- Your administrator removes access. Retry in a fresh session after the platform’s applicable refresh conditions.
- Expect
- New retrieval no longer exposes the record. Existing copies need a separate retention or deletion decision.
- If it fails
- Investigate remaining grants, sync behaviour or another access path before expansion.
Verification record
Permission change, refresh conditions, test time and observed output.
We agree expected results before testing. Findings apply to the tested scope and configuration.
Compliance & governance
Turn requirements
into evidence.
Your security and compliance owners set the requirements. We work with your delivery team to turn them into controls and evidence to verify.
Example: confidential employee records
- Requirement
HR access only
Your policy limits this collection to the HR team.
- Control
Scoped permissions
Source membership and connector access reflect that boundary.
- Evidence
Role-based results
Dated checks compare the authorised and restricted accounts.
- Open item
Owner & retest
Any gap or unverified path gets an owner and next action.
Your compliance owner determines applicability and sign-off. The pilot supports their review with technical evidence.
Frameworks and reference points
Agree the relevant internal policy, customer requirement or framework during scoping. Technical findings can inform an ISO 27001, ISO/IEC 42001 or NIST AI RMF review; this pilot does not certify compliance.
Our review approach draws on deployment and risk-management guidance:
Your launch decision
Know what
can proceed.
Receive the access map, verification record, prioritised actions and a launch decision brief. Your owner can see the evidence and remaining risks together.
Discuss your rolloutExample recommendation categories
- Proceed
- Agreed criteria met. Remaining risks accepted by your owner.
- Proceed within limits
- Named restrictions, remediation owners and a review date.
- Resolve before launch
- An unresolved exposure or missing evidence blocks the agreed criteria.
Aona recommends. Your team approves launch.
Why Aona
We build security
for how people
use AI.
Our FDSE service brings that product focus to your implementation’s access, data and policy decisions.
We work with your delivery team.
Internal engineers, a vendor FDE or an implementation partner. We review the agreed controls with the people building and operating them.
Your security owner gets the evidence.
Findings trace back to reviewed settings and test results, with open questions and retest conditions clearly recorded.
Service and software have separate scopes. Required tools and supported paths are confirmed before the pilot.
The first pilot
One rollout.
A defined scope.
- 1
- rollout
- 25
- users, maximum
- 12
- agreed checks
10 business days after prerequisites are ready.
One follow-up retest included.
See the full scope
- Environment
- One department, AI platform and tenant; one browser and operating system.
- Access
- One existing read-only connector and data collection; up to three roles and three test accounts.
- Guidance
- Four hours of security configuration guidance.
- Retest
- Up to three hours on original findings, within 30 calendar days of the initial report.
Representative checks, not an inspection of every employee or device.
What we need to begin
- An implementation lead, security owner and administrator.
- Required access, licences and up to three test accounts.
- Synthetic or sanitised data and agreed expected results.
Access or readiness delays move the start date.
Let’s scope
your pilot.
Tell us what you’re implementing, who is delivering it and the security questions to resolve.
Discuss a pilot Use the contact formWill this make our rollout compliant?
The pilot produces technical evidence against agreed requirements, including settings reviewed, test results and unresolved gaps. Your compliance and legal owners determine obligations and sign-off. Certification, legal advice and a full organisation-wide compliance assessment are outside this pilot.
When should Aona join?
Ideally, before data access and pilot criteria are fixed. Already implementing? We can scope a review around your current rollout. The pilot runs for 10 business days, starting once access, test data and the required owners are ready.
Can you work with our integrator or vendor FDE?
Yes. We agree checks with your security and compliance owners, review settings with the implementation team, and give findings to the people responsible for fixes. Aona reports verification results to your security owner; your team controls changes and launch.
How independent is the review?
Aona is separate from your implementation team and reports findings to your security or IT owner. Aona also supplies security software. This is a scoped review, not an independent audit opinion, certification or comprehensive penetration test. You approve launch.
How does the Aona platform fit in?
The platform provides ongoing AI visibility and protection on supported paths. We confirm coverage and software requirements during scoping. Service deliverables and software subscriptions are separate.
Does this cover agents that take actions?
This first pilot covers one employee AI rollout with one existing read-only connector. Write-capable agents, custom application testing, extra tenants and broader infrastructure reviews are outside this pilot.