How to Become an AI Security Engineer in 2027: Skills, Certs and First Projects

An AI assistant can answer questions, retrieve internal documents and call tools that change business records. 

Each capability creates security decisions: who can access the data, which instructions the system should trust and what happens when the model requests an unsafe action.

An AI security engineer helps teams make those decisions and build the controls behind them. 

If you are planning a move into the role in 2027, a useful route combines security fundamentals, an understanding of AI applications, practical training and projects you can explain in an interview. 

What does an AI security engineer do?

An AI security engineer protects AI systems across applications, data, models and infrastructure. 

Depending on the team, you might review an assistant’s design, test its handling of untrusted documents, restrict tool permissions or investigate changes to a model artefact. 

Here’s an example: 

A support assistant might retrieve a customer ticket containing instructions to reveal an internal note. Your job could involve reproducing the behaviour, tracing how the ticket reached the model and implementing a control that prevents access to the protected note. 

AI red teaming focuses on finding weaknesses through authorised testing. Engineering also involves fixing those weaknesses, monitoring the system and helping developers maintain the controls. 

The responsibilities can overlap, so read the job description carefully. 

Build the skills you will use on the job

Prioritise skills that let you follow a request through an application and explain what protects each step.

• Security fundamentals: Get comfortable with HTTP, APIs, authentication, authorisation, Linux, networking and logs. You should be able to explain how an application identifies a user and checks their access to a document or action. These foundations remain useful when a model becomes part of the workflow. 
• Python and application testing: Learn to call an API, handle JSON, write small scripts and use version control. Aim to build a test harness that submits cases and saves responses. Practice keeping credentials out of code, handling errors and making your setup reproducible.
• AI application architecture: Understand how a large language model, or LLM, uses its context, how tools connect to it and where data enters the system. Learn retrieval-augmented generation, or RAG, which retrieves documents to help answer a question. Trace the document from ingestion to retrieval and model output. 
• Threat modelling and assessment: Map the assets, entry points and trust boundaries in a small AI application. Explore prompt injection, sensitive information disclosure, data poisoning and supply chain risks. For each finding, identify what the attacker controls and connect the observed behaviour to a realistic consequence. 
• Defensive engineering and reporting: Practice enforcing permissions in application code, limiting tool capabilities and logging useful evidence. Build regression tests that run again after a change. Write findings with clear reproduction steps, impact, remediation and retest results so another engineer can act on them. 

Choose your starting point from your current experience. 

• A SOC analyst can build on investigation and logging skills while strengthening Python and application security. 
• A developer can build on coding experience while learning threat modelling and security testing. 

If you are new to both, begin with networking, operating systems and basic web security before specializing. 

Three portfolio projects to build

A useful project gives a reviewer evidence of how you investigated a risk, implemented a control and checked the result. Keep the scope small enough to finish and document properly. 

Build these projects in environments you control, using fictional data. Follow the scope of any training lab, and mock actions such as sending emails or changing records. If you use a hosted model API, set a spending limit where available and keep API keys out of the repository. 

Project 1: Build and harden a ticket summariser

Build a small Python app that uses a model to summarise fictional support tickets. 

Start with a clear summarisation prompt. For every test, save the ticket, model response, model identifier, and relevant settings. Run a set of normal tickets first to establish a baseline.

Then introduce prompt injection.

Test two routes:

• Direct injection: Put an instruction in the user message that asks the model to return PRACTICE_MARKER instead of a summary.
• Indirect injection: Place the same harmless instruction inside a retrieved support ticket.

Next, add a mocked record-update tool. It should only log update requests and never change real data. 

Test whether an injected ticket can make the model request an update. Then add an application-level permission check that blocks updates in the summarise-only workflow. 

You can explore more controls in the Prompt Defence room. 

After each change, rerun the same attack cases and the original clean tickets. Check whether the controls stop unwanted behaviour without hurting summary quality. 

Keep attempted tool calls separate from actions the application actually allows. Run each test several times and report the results alongside the model configuration.

Your repository should include:

• The Python application
• Clean and adversarial test cases
• A simple data-flow diagram
• A short before-and-after report

In the report, explain where the injected instruction entered the system, what happened before the controls were added, and what each defence changed. 

The project demonstrates prompt-injection testing, defensive application design, and careful interpretation of model behaviour. 

Project 2: Test document access in a RAG assistant

Build a question-answering assistant over around ten fictional documents.

Include a mix of public guidance and one restricted HR document containing a distinctive fake value.

Create two test users with different access rights. For every request, record which passages are retrieved and which ones are sent to the model. 

Use the RAG Security Fundamentals room to understand how retrieval works.

Then introduce an indirect prompt injection. Add an instruction to a public document telling the assistant to reveal information from the restricted HR note. 

Before judging the model’s response, check whether the injected passage actually reached the model. 

Next, test whether the unauthorized user can access the restricted information through:

• Normal questions
• Indirect prompt injection
• Different wording or retrieval queries

Then add the main control: enforce document permissions before retrieved content enters the model context. 

Use the authenticated user’s permissions to filter results. Restricted documents should never reach the model for users who cannot access them. 

Add an approval step for changes to the document collection as well. This creates a record of who added or changed content and how it entered the knowledge base. 

Retest both users after the changes. 

The authorized user should still receive the permitted information. The restricted passage should never appear in the unauthorized user’s model context. 

Your project should include:

• A simple retrieval and data-flow diagram
• Test cases for both users
• A test matrix showing expected and actual results
• Redacted retrieval traces
• The access-control changes
• A short before-and-after analysis

In your report, explain the difference between the model choosing not to follow a malicious instruction and the application preventing sensitive information from reaching the model at all. 

The project demonstrates secure RAG design, access control, retrieval testing, and protection of sensitive data throughout the application.

Project 3: Create an AI supply chain release check

Build a small Python checker that reviews a JSON manifest before an AI artefact is approved for a toy deployment.

Keep the exercise focused on metadata and file integrity. Use harmless dummy files rather than real model artefacts. 

For each artefact, record:

• Source
• Version
• Expected file hash
• Dependency versions

Maintain a separate trusted baseline that defines what is approved.

Then create four test cases:

• An approved artefact
• A file whose contents have changed
• An artefact from an unapproved source
• An artefact with an unpinned dependency

Your checker should compare each case with the trusted baseline and reject anything that breaks the release policy. 

Save a readable report for every run explaining why the artefact passed or failed. 

Use the AI Supply Chain Security module to frame the exercise around provenance, tampering, dependencies, and release controls. 

Be clear about what the hash check proves. A matching hash confirms that the file matches the expected copy. It does not prove that the file itself is safe. 

Do not load or execute untrusted model files. Keep the project limited to metadata checks and file inspection. 

Your repository should include: 

• The Python checker
• Sample JSON manifests
• Dummy artefact files
• Test outputs for all four cases
• A short release policy

The release policy should explain who maintains the trusted baseline, who can approve changes, and when additional review is required. 

The project demonstrates release automation, provenance checks, integrity verification, and security judgment. A reviewer should be able to run the examples, see why a release was blocked, and understand which risks still need deeper review.

How much does an AI security engineer earn?

AI security salaries vary by location, experience, employer, and the level of responsibility in the role. 

For 2027 planning, use recent job adverts and salary data as a guide rather than treating one figure as a universal benchmark. 

Where does AI1 fit into your certification plan?

TryHackMe’s AI1 certification tests practical AI security skills across areas such as threat modelling, prompt injection, jailbreaking, AI supply chain security, and data poisoning. 

The AI1 exam guide currently includes 13 hands-on scenarios in a browser-based assessment. The passing score is 70%, and the certification remains valid for three years. 

Note: The learning path and AI1 certification serve different purposes. Use the path to learn and practice the skills, then take AI1 when you can work through the scenarios and explain your decisions without relying heavily on guidance. 

AI1 can also sit alongside a broader security foundation. 

For example:

• SEC1 for core cybersecurity skills
• SAL1 for security analysis
• PT1 for penetration testing
• AI1 for practical AI security

Choose the foundation that matches the role you want, then use AI1 to add AI security skills alongside hands-on portfolio projects. 

Start your route into AI security

Start with the AI Security learning path to build the fundamentals and identify the areas you need to strengthen.

Then put those skills into practice. Begin with the ticket summariser project before moving into RAG security and AI supply chain security. 

Once you can assess the risks, implement controls, and explain your decisions without relying heavily on guidance, explore AI1 and plan your assessment.