AI Security Audit
A person with too much access mostly ignores it. A system uses it.
What is AI security audit?
An AI security audit maps what each AI system can actually reach, where the data it handles travels, and whether answers are being produced from the system permissions rather than from the permissions of the person asking.
Access is granted broadly during setup because narrow permissions take longer to work out, and the intention is always to tighten them after go live. That sentence has no owner and no date attached, so it does not happen.
With conventional software that leaves a risk somebody has to choose to exploit. With AI it is different, because a system asked a broad question will draw on everything within reach, without anybody deciding that it should.
The finding that worries organisations most is the permission boundary. Where a system can reach HR or finance records and any user can ask it anything, answers come back scoped to the system access rather than to the person asking.
What this is and what it is not
Duara audits AI system access and data flows for organisations in Kenya.
This is an audit rather than a penetration test. We map what systems can reach and where data goes rather than attempting to break in, and where a genuine intrusion test is what you need we will say so.
Who this is for
- AI systems were set up quickly
- You cannot say what data leaves your organisation
- Staff adopted tools without approval
- Nobody has reviewed permissions since go live
Industries we serve
- Banking and financial services
- Insurance
- Healthcare
- Telecommunications
- Public sector
- Any organisation running AI on internal data
Problems this solves
These are the findings that recur across almost every AI deployment we examine.
- Setup permissions never narrowed. Broad access is granted for speed and the tightening step has no owner and no date, so it stays broad indefinitely.
- Answers scoped to the system, not the user. Where a system reaches records the asker should not see, the permission boundary that applies is the wrong one.
- Credentials shared between systems. One account used by several integrations cannot be revoked without breaking things, and nothing shows which system acted.
- Data leaving without a record. Providers nobody registered receive data nobody tracked, and the first time anybody looks is usually during an incident.
What we deliver
A map of what each system can reach, where data actually travels, whether answers respect user level permissions, and a remediation list ordered by exposure.
A map of what each system can access
Where data actually travels, including overseas
Permissions broader than the task requires
Shared credentials identified
Whether answers respect user level permissions
A remediation list ranked by exposure
Features
- Reach mapped, not assumed. What a system can touch is established from configuration rather than from what somebody believes was granted.
- Permission boundaries tested. Whether a user gets answers drawn from records they could not open themselves, which is the finding organisations react to fastest.
- Shared credentials surfaced. One account serving several systems removes both revocation and attribution, and it is common enough to look for specifically.
- Data destinations listed. Which providers receive what, and in which countries, since that question usually arrives during an incident.
- Logging assessed honestly. Whether you could reconstruct what happened, because most AI deployments record almost nothing useful.
Benefits
- Access matches purpose. Narrowing reach to the task removes exposure that no amount of monitoring can offset.
- Users see only what they should. Correcting the permission boundary closes a gap that staff frequently discover by accident before anybody audits it.
- Revocation becomes possible. Separate credentials mean a single system can be shut off without taking others down with it.
- Data flows become answerable. Knowing where data goes turns a regulator or customer question into a straightforward reply.
What the audit maps
- System reach. Every data source, system and account an AI deployment can touch.
- Permission inheritance. Whether answers are scoped to the asking user or to the system own access.
- Credential separation. Whether each system has its own identity, which decides whether anything can be revoked or attributed.
- Data destinations. Which external providers receive data, and where they process it.
- Unregistered tools. AI services in use that nobody recorded, which are usually found through data flows rather than through asking.
- Logging coverage. What is recorded about what these systems did, and what could be reconstructed afterwards.
Poor logging limits what any audit can conclude. Where records are thin we can establish what a system is able to do and not what it has already done, and we state that distinction rather than letting a clean report imply more.
How the process works, step by step
A security audit usually takes two to four weeks depending on how many AI systems and integrations exist.
-
Step 1
Scoping
We agree which systems are in scope and confirm that this is an access audit rather than an intrusion test.
-
Step 2
Reach mapped
What each system can touch, established from configuration rather than from what was intended.
-
Step 3
Boundaries tested
Whether users receive answers built from records they could not otherwise open.
-
Step 4
Data flows traced
Where information actually goes, including providers nobody registered.
-
Step 5
Findings ranked
Ordered by exposure, with remediation that can begin before the report is finished where something is urgent.
Quality assurance and how we work
The commitments attached to examining how exposed an organisation is.
- We tell you immediately if something is urgent. A serious finding does not wait for a report to be formatted, and you should be able to act the same day.
- We do not claim nothing has happened. Where logging is thin we can show what a system is able to do, and absence of evidence in poor records is not evidence of absence.
- We say when you need a penetration test instead. This maps reach and data flow. Where you need somebody attempting an intrusion, that is different work and we will say so.
- We report to you and nobody else. Findings go to whoever you nominate, and we do not notify providers, regulators or anybody else on your behalf.
- We rank by exposure rather than by ease. Closing simple items first produces visible progress and leaves the thing that actually matters open.
Frequently asked questions about AI security audit
Why is over broad access worse with AI?
Because a person with excess permissions rarely exercises them, while a system asked a broad question draws on everything it can reach.
Why does setup access stay broad?
The intention is always to tighten it after go live, and that sentence has no owner and no date, so nobody does it.
What is the permission boundary problem?
Answers scoped to the system access rather than the asking user, so somebody receives information from records they could not open themselves.
How would we notice that ourselves?
Staff usually find it by accident before anybody audits for it, which is a poor way to discover it.
Why do shared credentials matter?
One account serving several systems means you cannot revoke one without breaking the others, and nothing records which system acted.
Can you tell us where our data goes?
Yes, including overseas destinations and providers nobody registered, which is usually the part organisations cannot currently answer.
How do you find tools nobody recorded?
Through data flows rather than by asking, since the tools nobody registered are the ones nobody will mention.
Is this a penetration test?
No. It maps what systems can reach and where data travels. Where you need somebody attempting an intrusion, that is different work.
Can you confirm nothing has been misused?
No, and any auditor who says otherwise is overreaching. Where logging is thin, poor records cannot demonstrate absence.
What if you find something serious?
You hear immediately rather than at report stage, since a finding you can act on today should not wait for formatting.
What is usually the first fix?
Narrowing reach. Access a system does not have cannot be misused, which no amount of monitoring can match.
Does it cover tools staff adopted themselves?
Yes, and those are frequently where data leaves the organisation without anybody having decided that it should.
How long does a security audit take?
Two to four weeks, depending on how many AI systems and integrations are in scope.
What level of access do you need from us?
Configuration exports and read access are usually enough, and we ask for the least that answers the question.
Does it check logging?
Yes, and it is regularly the weakest area. Most AI deployments record almost nothing that would allow reconstruction afterwards.
Can remediation start before the report?
Yes, and it should where something is urgent. Waiting for a document to be finished is not a security posture.
Will you tell our providers?
No. Findings go to whoever you nominate and we notify nobody on your behalf.
Does this cover models we host ourselves?
Yes, and self hosted systems still have reach and credentials, which are the subject here rather than where the model runs.
Who receives the access map?
Only the people you name. The report describes exactly how to exploit your weaknesses, so distribution should be tight.
What does a security audit cost?
The number of systems and integrations determines it, quoted after scoping.
Glossary of terms
Access audit terms in plain language.
- System reach
- Everything an AI deployment can touch, which is usually wider than anybody intended.
- Permission boundary
- Whether an answer is limited by the asking user access or by the system own.
- Shared credential
- One account used by several systems, which prevents both revocation and attribution.
- Data destination
- Where information actually travels, including providers and countries nobody recorded.
- Unregistered tool
- An AI service in use that no inventory contains, usually found through data flows.
- Logging coverage
- What was recorded about system activity, which decides what can be reconstructed later.
Related services in AI Audit Services
Talk to us about AI security audit
Ask your AI system a question about something you should not have access to. The answer is the audit finding.
Start your project