Securing AI Systems · Topic 3 of 7
Access Controls for Models, Data, Agents and APIs
Apply access controls to AI systems: model access, training and RAG data access, least privilege agent access, and network and API access to models.
- 6 min
- Includes a diagram
- Separate model permissions: query, configure, train, export and release are different rights.
- Restrict write access to training data, because it is the path to poisoning.
- Enforce the user's own permissions when an agent or RAG system retrieves data.
What it is
Access control decides who or what may use, change or reach each part of an artificial intelligence (AI) system. The objectives split it into four areas: model access, data access, agent access and network and application programming interface (API) access.
The principles are the familiar ones: authenticate every identity, grant least privilege, separate duties and log use. What changes with AI is that a model or agent can act for a user, so its permissions must never exceed what that user is allowed.
How it works
Model access
Models are valuable assets. Their weights represent the cost of training, and anyone who can change them can change the system's behaviour.
| Action | Who should have it |
|---|---|
| Query the model for answers | Approved users and applications, through the gateway |
| Change the system prompt, guardrails or configuration | A small group of administrators, under change control |
| Fine-tune or retrain | Machine learning engineers in the training environment |
| Download or export model weights | Very few people, with approval and logging |
| Publish a model version to production | A release role separate from the developers who trained it |
Store models in a model registry with role-based access control (RBAC), versioning and signatures, so only approved versions are deployed.
Data access
Data access covers training data, evaluation data, retrieval-augmented generation (RAG) sources and logs of prompts and responses. Each needs its own permissions.
- Training data: write access for few people, because write access is the path to data poisoning.
- RAG sources: apply the asking user's permissions at retrieval time, not the service account's broader access.
- Prompt and response logs: they often hold sensitive data, so restrict reading to investigators and auditors.
- Attribute-based access control (ABAC): use labels such as department or classification to filter what each user's queries can retrieve.
Agent access
An AI agent is a model that can plan and take actions through tools, such as sending email, querying databases or changing tickets. Its access is the access of every tool it can call.
| Control | Purpose |
|---|---|
| Dedicated agent identity | Each agent has its own account, so its actions are traceable and revocable |
| Least privilege tool scopes | Read-only where possible; only the tools the task needs |
| Act on behalf of the user | The agent uses a token limited to the requesting user's rights, so it cannot reach data the user cannot |
| Short-lived credentials | Tokens that expire quickly limit damage if stolen |
| Human approval for high-impact actions | Payments, deletions and permission changes wait for a person |
| Allow lists of tools and destinations | The agent can call only listed tools and reach only listed domains |
The risk to avoid is the confused deputy, where a privileged agent is tricked into using its rights for someone who lacks them. Scoping the agent to the user's own permissions removes most of that risk.
Network and API access
| Control | Example |
|---|---|
| Strong API authentication | Open Authorization (OAuth) tokens or managed keys per application, never shared keys in code |
| Key management | Store keys in a secrets vault, rotate them and revoke unused ones |
| Private endpoints and segmentation | Model endpoints reachable only from internal networks or approved services |
| Mutual Transport Layer Security (mTLS) | Both client and server prove their identity with certificates |
| Egress filtering | Agents and model servers can reach only approved external destinations |
| Gateway enforcement | All traffic goes through the AI gateway, where rate limits and logging apply |
A worked example
A company deploys an internal agent that answers human resources (HR) questions and can update an employee's own address. Testing shows a user can ask it for a colleague's salary, and it complies because its service account reads the whole HR database.
The fix replaces the broad service account with on-behalf-of access tied to the requesting user, limits the update tool to the user's own record, and puts the endpoint on a private network behind the gateway. Address changes now also need a confirmation from the user.
How the exam asks about this
- "An AI agent with a broad service account returns records the requesting user is not allowed to see. Which of the following is the best fix?" Make the agent act with the requesting user's permissions, applying least privilege to its tools.
- "Developers have been sharing one hardcoded API key for a model service in source code. Which of the following should the security team implement?" Per-application keys stored in a secrets vault, with rotation and revocation of the shared key.
- "Only the release team may promote a model version to production. Which of the following controls supports this requirement?" Role-based access control on the model registry, separating training and release roles.
What to remember for the exam
- Separate model permissions: query, configure, train, export and release are different rights.
- Restrict write access to training data, because it is the path to poisoning.
- Enforce the user's own permissions when an agent or RAG system retrieves data.
- Give agents dedicated identities, least privilege tools, short-lived tokens and human approval for high-impact actions.
- Protect APIs with per-app authentication, vaulted and rotated keys, private endpoints and egress filtering.
An agent can do anything its credentials allow, and a prompt injection can direct it. Limit the credentials first; do not rely on the model refusing.
Common mistakes
Giving the AI service broad read access "so it can answer anything". That turns every user into someone who can read everything the service can. Filter by the user's rights.
Treating model weights as ordinary files. Exported weights let an attacker copy the model or study it offline for attacks. Restrict and log export.
Sharing one API key across teams. A shared key cannot be traced to one application or revoked without breaking all of them.
Check yourself
What is a confused deputy in an AI agent?
A privileged agent that is tricked into using its own access on behalf of someone who should not have it.
Why should write access to training data be tightly restricted?
Anyone who can change training data can poison it and alter the model's behaviour.
Name two network controls for a model endpoint.
Private endpoints that keep it off the public internet, and mutual TLS or strong API authentication for every client.
Topic 3 of 7 in Securing AI Systems
Test yourself on Securing AI Systems
The full CompTIA SecAI+ CY0-001 question bank has 654 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by CompTIA. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.