TryHackMe LockdownAI Walkthrough: Securing a RAG AI Assistant

Overview

TryHackMe LockdownAI takes a different approach from the usual penetration testing room. Instead of enumerating ports, finding a vulnerable web application, and eventually gaining a shell, this challenge puts you in the role of a security engineer auditing an internal AI assistant.

The fictional company, Meridian Security Group, has deployed an AI assistant called Bastion. Bastion uses Retrieval-Augmented Generation, better known as RAG, to retrieve company information and provide answers to employees. A security audit has identified three problems with the system, and our job is to determine exactly what is wrong and recommend the proper security control for each issue.

I liked this room because there really isn’t an exploit in the traditional sense. You aren’t trying to get reverse shells or abuse a service. Instead, you have to understand how an AI application retrieves information, stores logs, and separates data belonging to different users.

Note: This walkthrough does not include TryHackMe flags, flag fragments, passwords, or room answers. The goal is to explain the methodology and security concepts while leaving the challenge itself intact.

Room: TryHackMe LockdownAI
Difficulty: Medium
Category: AI Security / RAG Security
Primary Concepts: Access Control, RAG, Logging Security, Tenant Isolation

What Is RAG?

Before working through the vulnerabilities, it helps to understand what Bastion is actually doing.

Retrieval-Augmented Generation (RAG) combines a Large Language Model with an external source of information. Instead of relying entirely on what the model learned during training, the application retrieves relevant documents and places that information into the context provided to the LLM.

A simplified RAG request may look something like this:

User Question
     ↓
Authentication / Authorization
     ↓
Vector Database Search
     ↓
Relevant Documents Retrieved
     ↓
Documents Added to LLM Context
     ↓
LLM Generates Response
     ↓
Response Returned to User

That additional retrieval layer is incredibly useful, especially for internal company assistants. An organization could place policies, documentation, procedures, knowledge-base articles, and other information into a searchable collection and allow employees to ask questions using normal language.

The security problem is that the retrieval system may also contain information that every employee should not be allowed to access.

If authorization happens after sensitive information has already been retrieved, the security boundary is in the wrong place.

That idea becomes extremely important during this room.

Beginning the Audit

Bastion provides several commands that help us understand how the system operates.

STATUS

The STATUS command provides an overview of the system’s current security state.

The room identifies three areas that require investigation:

Vulnerability	Security Concern
Open Retrieval	Unauthorized documents may be retrieved
Verbose Logging	Sensitive information may be written to logs
No Tenant Isolation	Users may access another user’s information

Rather than thinking of these as three unrelated vulnerabilities, I found it easier to look at them as three different places where an AI system needs access control.

We need to control what the AI retrieves, what the application records, and whose information a user is allowed to access.

Vulnerability 1: Open Retrieval

The first problem exists inside the RAG retrieval process itself.

Bastion can search documents stored inside its vector database, but the retrieval operation does not properly restrict those documents based on the requesting user’s permissions or clearance level.

That means a query could potentially cause restricted information to become part of the documents supplied to the LLM.

Why This Is Dangerous

A common mistake when designing an AI assistant is relying on the model itself to protect sensitive information.

The architecture effectively becomes:

User
  ↓
Search Everything
  ↓
Retrieve Sensitive Documents
  ↓
Send Everything to LLM
  ↓
Tell LLM Not to Reveal Sensitive Information

That isn’t a reliable security boundary.

Once confidential information reaches the model’s context window, the model already has access to it. Prompt injection, application mistakes, unexpected model behavior, or future configuration changes could expose that information.

The better architecture is:

User
  ↓
Determine User Permissions
  ↓
Filter Authorized Documents
  ↓
Perform Vector Search
  ↓
Send Authorized Results to LLM

The important difference is that unauthorized documents are never retrieved in the first place.

Fixing Open Retrieval

The appropriate defense is metadata pre-filtering at the retrieval layer.

Documents stored in the RAG knowledge base should contain metadata describing who is allowed to access them. That might include fields such as:

department
role
clearance
tenant_id
document_owner
classification

Before performing vector similarity search, the application should use the authenticated user’s permissions to restrict which documents are eligible for retrieval.

For example:

User Role: Human Resources
Department: HR
Clearance: Internal

The vector search should only search documents matching those permissions.

Restricted documents never become retrieval candidates and therefore never enter the LLM’s context window.

Security Lesson

Authorization should happen before retrieval, not after generation.

The LLM should not be responsible for deciding whether a user is allowed to see information. That decision belongs to deterministic application and data-layer security controls.

[Screenshot – Open Retrieval Investigation]

Vulnerability 2: Sensitive Data in Logs

The next area to investigate is Bastion’s logging behavior.

The room provides:

SHOW LOGS

Examining the logs reveals another interesting problem. Bastion records far more information than it actually needs for operational logging.

The logs contain information relating to user queries and retrieved documents.

This creates a second copy of potentially sensitive data.

Why Verbose AI Logging Is Dangerous

Logging is extremely important. As someone who spends a lot of time working with SIEM systems and security monitoring, I definitely wouldn’t recommend solving this problem by simply turning logging off.

Logs are needed for troubleshooting, auditing, incident response, performance analysis, and threat detection.

The problem is what gets logged.

Consider a RAG system that records:

Timestamp
Username
Entire User Prompt
Entire Retrieved Document
Entire AI Response

If those documents contain confidential information, the logging system has effectively become another sensitive database.

An attacker might not even need to compromise the original vector database. Access to an improperly secured log server could expose the same information.

This is especially dangerous when logs are forwarded into additional systems such as:

• SIEM platforms
• Cloud logging services
• Development dashboards
• Debugging platforms
• Log aggregation servers
• Backup systems

One piece of sensitive information can suddenly exist in several different locations.

Fixing Verbose Logging

The proper defense is log sanitization combined with data minimization.

The application should record enough information to investigate an event without storing the sensitive content involved in that event.

A safer log might contain:

timestamp
user_id
request_id
document_id
action
status
response_code

Instead of:

complete user query
complete document contents
PII
confidential business information
credentials
sensitive AI responses

Sensitive values should be removed, redacted, masked, or tokenized before the log entry is written.

Logs should also be protected with traditional security controls, including:

• Role-based access control
• Encryption at rest
• Encryption in transit
• Defined retention periods
• Centralized monitoring
• Integrity protection
• Regular auditing

Why Not Disable Logging?

One of the important lessons from this room is that less logging does not mean no logging.

If something goes wrong with an AI assistant, security teams still need enough telemetry to determine what happened.

The goal is to log the event, not unnecessarily duplicate the data involved in the event.

[Screenshot – Bastion SHOW LOGS Results]

Vulnerability 3: Broken Tenant Isolation

The third vulnerability involves user separation.

Bastion provides another interesting command:

QUERY AS: [user]

The purpose of this functionality is to test how the system behaves when operating in another user’s context.

The problem is that Bastion does not properly enforce boundaries between those identities.

This creates a classic broken access control problem, except now it exists inside a RAG and vector-database architecture.

What Is Tenant Isolation?

A tenant can represent a user, department, customer, company, organization, or another logical ownership boundary.

Imagine a cloud-based AI assistant serving three organizations:

Vector Database
├── Company A
│   ├── HR Documents
│   └── Internal Policies
│
├── Company B
│   ├── Contracts
│   └── Engineering Documentation
│
└── Company C
    ├── Financial Records
    └── Security Procedures

Company A should never be able to retrieve documents belonging to Company B simply by manipulating a prompt or changing an identity field.

The same principle applies inside a single company.

An HR employee, salesperson, contractor, system administrator, and executive may all have legitimate access to the same AI assistant while having completely different permissions to the underlying information.

Why Application-Layer Filtering Isn’t Enough

One tempting solution would be retrieving the information first and filtering the results afterward.

Again, that puts the security control too late in the process.

Search Entire Database
        ↓
Retrieve Documents
        ↓
Send Documents to Application
        ↓
Determine What User Should See

Sensitive information has already crossed the authorization boundary.

Tenant isolation should instead be enforced by the retrieval infrastructure itself.

Authenticate User
        ↓
Determine Tenant
        ↓
Restrict Search Namespace
        ↓
Perform Vector Search
        ↓
Return Authorized Documents

The user never has an opportunity to search outside the authorized dataset.

Fixing Tenant Isolation

The proper remediation is tenant-scoped authorization enforced at the vector database layer.

Every request should be associated with an authenticated identity, and that identity should map to an authorized tenant or dataset.

The application should not trust something supplied through a prompt such as:

QUERY AS: another-user

as proof of identity.

Instead, identity should come from a trusted authentication mechanism such as:

• SSO
• OAuth/OIDC
• Kerberos
• Active Directory
• Signed authentication tokens
• Application sessions

The vector database query should then enforce the tenant restriction independently of whatever the user places into the prompt.

Security Lesson

Prompts are user input, not authentication.

Anything the user can type should be treated as untrusted input.

[Screenshot – Tenant Isolation Testing]

The Three Security Problems Together

What I liked most about LockdownAI is that the three vulnerabilities build on each other.

Layer	Vulnerability	Proper Defense
Retrieval	Unauthorized documents can enter the LLM context	Metadata pre-filtering
Logging	Sensitive information is written into logs	Log sanitization and data minimization
Vector Database	Users can access another user’s data	Tenant-scoped authorization

Fixing only one layer isn’t enough.

For example, you could perfectly secure tenant isolation while still dumping confidential information into plaintext logs.

You could sanitize every log while still allowing the RAG engine to retrieve documents the user isn’t authorized to see.

AI applications still require defense in depth.

AI Security Is Still Security

One of my biggest takeaways from this room is that many so-called “AI vulnerabilities” are really familiar security problems appearing inside a new architecture.

Open retrieval?

That’s an access control problem.

Cross-user data exposure?

That’s broken authorization.

Sensitive information in logs?

We’ve been dealing with that problem for decades.

The technology is different, but the security principles really aren’t.

Authentication, authorization, least privilege, data minimization, secure logging, and separation of duties still matter. The difference is understanding where those controls belong inside an AI pipeline.

Why the Retrieval Layer Matters

With a normal application, developers may retrieve a database record after checking whether a user has permission to access it.

RAG systems need the same mindset.

A vector similarity search doesn’t inherently understand authorization. Its job is basically:

Find the documents mathematically closest to this query.

If a confidential document happens to be the best semantic match, the vector database may happily return it unless some additional mechanism tells it not to.

That is why document metadata and retrieval filtering are so important.

The authorization system needs to answer a completely separate question:

Is this document allowed to participate in this user’s search?

Only after answering that question should similarity search occur.

Real-World Defensive Checklist

If I were reviewing a production RAG application after completing this room, these are some of the first areas I would investigate.

Authentication

• Are users strongly authenticated?
• Is MFA supported?
• Can identity information be manipulated through prompts or request parameters?
• Does the backend independently validate the authenticated identity?

Retrieval

• Are authorization rules enforced before vector search?
• Do documents contain appropriate access-control metadata?
• Can restricted documents ever enter an unauthorized model context?
• Is document-level access control enforced server-side?

Vector Database

• Are tenants logically or physically separated?
• Are namespace restrictions applied on every query?
• Can a user manipulate a tenant ID?
• Are authorization decisions based on trusted identity information?

Logging

• Are complete prompts being stored?
• Are retrieved documents stored in logs?
• Could logs contain PII, credentials, or confidential information?
• Who has permission to access AI application logs?
• How long are logs retained?

Monitoring

Security teams should also look for unusual behavior such as repeated attempts to access restricted documents, unusual tenant identifiers, excessive retrieval requests, suspicious prompt patterns, and repeated authorization failures.

These events can then become detection opportunities inside a SIEM.

Defensive Architecture

A simplified secure RAG workflow might look like this:

User
  ↓
Authentication
  ↓
Authorization
  ↓
Tenant Resolution
  ↓
Metadata Pre-Filtering
  ↓
Vector Similarity Search
  ↓
Authorized Documents Only
  ↓
LLM
  ↓
Output Validation
  ↓
Response

Logging should happen alongside that process, but the logs themselves should contain only the metadata necessary for auditing and investigation.

Request ID
User ID
Tenant ID
Document IDs
Timestamp
Action
Result

Sensitive document contents should remain in the systems specifically designed to protect that information.

Lessons Learned

TryHackMe LockdownAI turned out to be less about attacking artificial intelligence and more about understanding where traditional security controls fit into modern AI architecture.

The three vulnerabilities are simple once you understand them, but they highlight some very real mistakes organizations could make while rapidly deploying internal AI systems.

The biggest lesson for me was that an LLM is not an access-control system.

You can’t retrieve everything, hand it to the model, and rely on a prompt saying, “Don’t show confidential information.”

Sensitive information should never reach the model unless the authenticated user is authorized to access it.

Likewise, logging and tenant isolation need to be treated as independent security boundaries rather than features the AI model is expected to understand.

Key Takeaways

Main lesson: RAG applications require traditional security controls at the retrieval and data layers. The AI model itself should never be responsible for enforcing authorization.

Important commands:

STATUS
SHOW LOGS
QUERY AS: [user]

Skills practiced:

• RAG security auditing
• AI access-control analysis
• Vector database security
• Document-level authorization
• Log sanitization
• Data minimization
• Tenant isolation
• Broken access-control identification

Defensive considerations: Authenticate users independently of prompts, apply authorization before retrieval, isolate tenants at the data layer, minimize sensitive logging, and monitor AI applications using the same defense-in-depth principles applied to traditional systems.

References

• TryHackMe – LockdownAI
• 0xuki – TryHackMe LockdownAI: Auditing a RAG Assistant for Three Hidden Vulnerabilities
• OWASP – Top 10 for Large Language Model Applications
• More Walkthroughs