Learn AI /AI Security /Authentication and authorisation
Authentication and authorisation
- Starter
- AI Security
- Technical readers
Also called: authentication, authorisation, authorization, login.
Back to the milestone you came from
In five seconds
What it is
Authentication verifies a claimed identity; authorisation checks what that requester is allowed to do.
In plain words
First the system checks who is asking. Then it checks what that person or service is allowed to do.
An everyday example
At reception, Noor shows identification and confirms the booking. That verifies who she is. She then receives a key card programmed for her room and the guest lift, but not the staff office or another guest’s room. The identity check is authentication. The doors the card is permitted to open are authorisation. Passing the first check does not make every door available.
A library clerk makes a human judgement and can ask follow-up questions. Digital systems usually follow preset rules automatically and at high speed. Also, in real systems, authentication may happen with tokens, certificates or device checks rather than a person showing one card once at a front desk.
Remember thisAuthentication verifies who or what is making the request. Authorisation decides whether that verified requester may perform a particular action on a particular resource.
Understand it
Understand it
Why it matters
For most people, the practical question is not just 'Can I sign in?' but 'What can this account, app or AI tool do once it is inside?' That affects security, privacy, safety and accountability. If authentication is weak, the wrong person or service may get in. If authorisation is too broad, a legitimate account can still expose data, trigger the wrong action, or let an AI-connected tool reach more than it should. In AI settings, this is especially important because a model may be connected to documents, email, databases or external tools. Clear identity checks and narrow permissions help contain errors, misuse and attacks, even when they do not prevent them entirely.
From identity check to permitted action
Show the difference between authentication, login and authorisation, and explain why they happen in that order.
01
1. Request begins
A person, device or service asks to use a system or tool and presents some credential, such as a password, code or token.
Draw a user icon and a service icon feeding a credential badge into the first card. Label inputs 'password', 'security key', 'token'.
02
2. Authentication
The system checks whether the credential matches the claimed identity. If it fails, the process stops here.
Show a shield with a tick and a crossed path beneath it. Add a short note: 'Proves who is asking'.
03
3. Authorisation
If identity is verified, the system checks rules or roles to see what that identity may do.
Show a list with items like 'view', 'edit', 'download' and only some highlighted. Add a note: 'Checks allowed actions'.
04
4. Outcome
The result can be full access, limited access, or denial for some actions even though sign-in succeeded.
Show three output badges: 'view only', 'edit allowed', 'denied'. Use distinct colours and icons.
A four-step left-to-right diagram. Each card shows one stage in an access request: claim identity, verify identity, check permissions, allow or block specific actions. Read from left to right to see what goes in, what the system checks, and what comes out.
On hover or tap, each step reveals one example: password for authentication, staff role for authorisation, and a view-only result for outcome.
Describe this without the diagram
The diagram explains access as four ordered stages. First, a requester sends credentials such as a password, security key or token. Second, authentication checks whether the requester really matches the claimed identity; if not, the request ends. Third, authorisation checks rules, roles or permissions for that verified identity. Fourth, the system returns an outcome such as view only, edit allowed or denied. The key point is that login is just one visible sign-in moment, while authentication verifies identity and authorisation determines permitted actions.
With reduced motion: A static four-card sequence with arrows between the cards and example labels under each stage, showing the same order and outcomes without animation.
These words are related, but they are not the same. Authentication checks an identity claim: do the credentials support the claimed person, device or service? Authorisation checks permissions: now that the claim has been checked, what is that requester allowed to read, use or change? Login usually means the sign-in step people see on screen, but a system can authenticate and authorise in other ways too.
What goes in depends on the system. It might be a password, a code from an app, a security key, or a digital token. A token is a piece of data that may represent a session, identity, granted scope or other claims. The system compares that information with its records or with another trusted service.
What happens next has two parts. First, the system tries to verify the identity claim. If that succeeds, it then looks up rules or roles, such as “staff can view this page” or “editors can approve changes”. What comes out is not just yes or no. The result may be “signed in but view only”, “signed in with editing rights”, or “access denied”.
In AI systems, this matters because many incidents are not about breaking encryption or guessing passwords. They are about getting a model, plugin or connected tool to act beyond its allowed scope. Good authentication and authorisation do not stop every AI attack, such as prompt injection, but they limit what a compromised session, tool or application can reach.
How “Checking into a hotel” maps onto the real thing
| In the story | In the AI system |
|---|---|
| library card check | authentication: verifying identity or session |
| membership type or researcher pass | authorisation data such as role, group or permission |
| reading room versus rare manuscripts room | different levels of access to tools, files or actions |
| desk clerk decision after checking records | system evaluating credentials and access rules |
A worked example
A budget officer is coding open-ended needs assessment answers with an approved internal AI assistant. The officer asks it to classify a de-identified extract and upload the coding table to the regional bureau’s progress report folder.
Starting from: Verified bureau account using a security key. Requested actions: read the de-identified extract, call the classification function and write the coding table to the progress report folder.
- The identity service verifies the account and security key, then issues a session token representing the authenticated session.
- The assistant checks authorisation for each requested action. The officer may read the de-identified extract and call the classification function.
- A separate check finds that the officer has read access, but not write access, to the progress report folder while the file is under clearance.
- The assistant produces the coding table in the officer’s authorised workspace but blocks the upload and records the reason.
Result: Authentication succeeded. Authorisation permitted reading and classification, but denied writing to the folder under clearance. The officer can send the coding table through the established clearance process rather than bypassing the folder controls.
In a United Nations workplace
At close of business, a budget officer in a regional bureau uses an approved internal AI assistant to code de-identified, open-ended answers from a needs assessment before the progress report goes for clearance.
Authentication verifies the officer’s identity through the bureau account and security key. Authorisation separately checks whether that account may read the de-identified extract, call the coding function and write the output to the progress report folder. Permission for one action does not confer permission for the others.
Before you try thisDo not enter raw answers containing personal, medical, protection-sensitive or other confidential information into a tool that has not been approved for that material. Access to the AI assistant does not authorise access to the underlying response file, and de-identification must not be assumed merely because names were removed.
Where you may hear it
- A vendor demo before an information and communications technology governance board
- A regional bureau access review before an AI assistant goes live
- A procurement meeting on service accounts and tool permissions
- A help-desk call after a colleague can sign in but cannot open the file
Avoid confusion
Avoid confusion
Often confused with
Access control
Access control sets rules about which people, systems or AI tools can view, use or change specific data, functions and resources.
Shadow AI
Use of AI tools outside approved organisational processes, especially where data, security, legal or oversight rules are bypassed.
Common misconceptions
Common misconception: Authentication and authorisation are just two words for logging in.
Correction: They are linked but different. Authentication verifies identity. Authorisation checks permissions after identity has been verified. Login is only one common user-facing moment in that process.
Common misconception: If a user can open an AI tool, the tool can do anything the organisation can do.
Correction: Access should be narrower than that. A tool may be available to many users, but its connected actions should still be limited by role, data source and task. Good design gives the minimum access needed, not automatic broad access.
Common misconception: Once authentication succeeds, later checks are unnecessary.
Correction: A verified identity does not answer every permission question. Systems often need to check authorisation again for each file, tool or action because permissions can differ and can change over time.
Quick check
A staff member signs in successfully to an AI tool but cannot export a dataset. What best explains this?
Successful sign-in shows that the initial authentication step worked. Exporting data is a separate permission question. The audit message shows that authorisation rules denied that action.
Go deeper
Go deeper
The simple version
First the system checks who is asking. Then it checks what that person or service is allowed to do.
The technical version
Authentication establishes or verifies an identity claim using credentials such as passwords, security keys, certificates or tokens. Successful authentication may create a session or issue a token representing that verified state. Authorisation then evaluates policy for that identity, session or workload: roles, attributes, group membership, resource rules or scope. The output is a decision about specific actions on specific resources, such as read, write, execute or call-tool permission. Login is a common interactive entry point for human users, but machine-to-machine systems may authenticate and authorise without a visible login screen. These concepts are related to access control, but they are not identical: authentication and authorisation are mechanisms within the broader control of who can do what, under which conditions.
Reviewed external resources
Primary sourceOWASP Top 10 for LLM Applications (opens in a new tab)OWASP
A practical security guide that helps technical and policy readers see how identity and permission issues appear in LLM applications.
Intermediatelink checked 2026-07-31
Primary sourceAdversarial Machine Learning: A Taxonomy and Terminology (opens in a new tab)NIST
A more formal terminology resource for readers who want careful definitions and a wider security context for AI systems.
Deeperlink checked 2026-07-31
EncyclopaediaAuthentication (opens in a new tab)Wikipedia
A broad introductory reference to authentication concepts and terminology, useful for general readers who want a quick overview.
Intermediatelink checked 2026-07-31
VideoVideo explanations: Authentication and authorisation (opens in a new tab)YouTube search
A search results page that can help beginners find different video teaching styles on authentication and authorisation, but it is not a single vetted lesson.
search results, not one pagelink checked 2026-07-31
DiscussionCommunity discussion: Authentication and authorisation (opens in a new tab)Reddit search
A search results page showing community discussions and examples of confusion about these terms, most useful for informal exploration and not as an authoritative source.
search results, not one pagelink checked 2026-07-31
Where this came from
Drafted with a language model through an offline pipeline, checked against this site's schema, and every external link above fetched to see whether it answers. Treat it as a starting point and check anything that matters against the primary sources. How this site is built and what that means.
The one thing to remember
Authentication verifies who or what is making the request. Authorisation decides whether that verified requester may perform a particular action on a particular resource.