From Almost No AI Security Experience to 100/100: My OffSec OSAI (AI-300) Journey

##Introduction#

On August 3, 2026, I attempted OffSec's AI-300 exam. Sixteen hours later, I had completed the objectives that ultimately earned me 100 out of 100 points. I received the result on August 5.

My result might suggest that I came into the course with significant AI security experience. I did not.

Before AI-300, I had little to no practical knowledge of AI security or vulnerabilities specific to AI-enabled systems. My background is primarily in web, mobile, and API penetration testing, which is also the focus of my day-to-day work. I had previously earned OSCP, OSWE, and OSEP, so I was comfortable with OffSec's style of practical learning and knew what I wanted from the course: a structured path into an unfamiliar field.

That is exactly where AI-300 worked well for me.

##Why I Chose AI-300#

AI security is quickly becoming relevant to penetration testers and security consultants. I wanted to understand the new attack surfaces introduced by modern AI systems, but I did not want to build that knowledge from disconnected articles, tools, and isolated examples.

Because this was an OffSec course, I expected the content to connect the dots progressively: introduce a concept, demonstrate why it matters, provide an environment in which to practise it, and then build upon it. The course largely met that expectation.

OffSec positions AI-300: Advanced AI Red Teaming as hands-on training for assessing AI-enabled environments. The course page lists approximately 65 hours of content and recommends an OSCP-level foundation or equivalent experience.

That prerequisite matters. AI-300 can be a starting point for AI security, but it is not intended to be a person's first cybersecurity course.

##My Preparation Timeline#

I enrolled through the pre-sale offer, which provided four months of course and lab access beginning on March 31.

I spent approximately two weeks going through the course material and another two weeks working on the labs. I did not use external AI security courses or study material. My preparation came entirely from AI-300.

My previous penetration-testing experience made the traditional web and host exploitation portions relatively comfortable. That freed up attention for the part that was genuinely new to me: how AI components change the trust relationships inside a system.

##Course and Lab Experience#

The strongest part of AI-300 is its coverage. The content felt current, focused, and relevant to the systems security consultants are increasingly likely to encounter. I never felt that an important prerequisite had been silently skipped, nor did I feel that the course was padded with unnecessary material.

For someone with limited AI security knowledge but solid penetration-testing fundamentals, the progression is approachable. The exercises included within the chapters are useful because they turn an abstract concept into something observable. Instead of treating AI security as prompt injection alone, the course presents AI-enabled applications as complete systems, and assesses them as such.

The areas I found most valuable were:

• AI supply-chain security
• MCP and tool surfaces
• RAG architectures and their trust boundaries

These topics reinforced an important idea: the model is only one part of the attack surface. The surrounding integrations, permissions, data flows, and deployment decisions can be equally important.

I fully completed three challenge environments and worked through substantial portions of two others. At a conceptual level, the labs prepared me well for the exam. The techniques and underlying ideas were comparable, although some exam paths required more independent thinking and did not feel like direct repetitions of a lab recipe. That difference was appropriate for a practical certification.

##What the Labs Actually Taught Me#

My most valuable lab notes were not collections of payloads. They were a methodology for staying oriented during a long, multi-host engagement.

The environments taught me to:

1. Map hosts, services, identities, and reachable network segments before committing to an attack path.
2. Separate verified facts from assumptions.
3. Track where every credential or artifact was found and where it had been tested.
4. Maintain a chronological record of actions, results, interpretations, and next steps.
5. Record dead ends so that neither I nor an AI assistant repeated them without new evidence.
6. Re-enumerate when actual system behaviour contradicted my expectations.

This discipline became more valuable than memorizing any one technique. In complex environments, wasted time often comes from losing track of state: using stale information, confusing one type of credential for another, assuming that one reachable service implies another, or repeatedly pursuing a hypothesis that evidence has already disproved.

The practical rule I carried into the exam was simple: when something does not work as expected, step back and enumerate again.

##The Exam#

The public OSAI Exam Guide describes a 24-hour, proctored red-team engagement against an AI-enabled enterprise environment. It contains two independent attack chains, a mixture of AI-focused and traditional vectors, and 100 available points. A score of 75 is required to pass, followed by a separate 24-hour reporting window.

I worked on both attack chains in parallel rather than completing one before touching the other. This worked well for me because it allowed enumeration and troubleshooting to continue across the environment without making all progress dependent on a single hypothesis.

Compared with the course and challenge labs, the exam felt broadly similar, but a few attack paths required more out-of-the-box thinking. Avoiding rabbit holes was the hardest part. The technical difficulty of an individual step was not always the main challenge; deciding whether a path deserved more time was often more important.

I reached 100 points in approximately 16 hours. I also took regular breaks, generally every one to two hours. Those breaks helped me return to unresolved problems with a clearer view rather than continuing to push the same unproductive approach.

##How I Used AI During the Exam#

AI use is not merely permitted in OSAI. OffSec's public guide strongly encourages it throughout reconnaissance, analysis, exploitation, troubleshooting, and interpretation, and warns that candidates who do not use AI will likely find the exam extremely challenging.

My primary assistant was Claude Opus 4.8. I had been approved for Anthropic's Cyber Verification Program, which supports qualified practitioners carrying out legitimate work such as vulnerability research, penetration testing, and red teaming.

Even with that approval and a clear statement that I was working inside an authorized lab, I occasionally encountered guardrails. When that happened, I did not waste time repeatedly rephrasing the same request. I asked Claude to produce a complete handoff containing the verified state, relevant evidence, attempted approaches, and next objective. I then continued the authorized task using Codex 5.6 Luna. This preserved operational context while allowing me to keep moving.

AI helped significantly with:

• Organizing enumeration across multiple hosts and services
• Reviewing evidence and identifying gaps
• Producing or adapting scripts to reduce repetitive work
• Troubleshooting failed approaches
• Maintaining a running engagement log
• Preserving context during model handoffs

The important phrase here is "with proper steering." AI was not an autonomous solve button. I still had to define the objective, validate its conclusions, recognize incorrect assumptions, decide when to change direction, and verify each result directly.

I also had to remind the assistant to maintain its logs after context compaction. Long engagements can outgrow an active context window, and information that is not stored explicitly can disappear from the working state. Durable notes made the AI more useful and made my own decisions more reliable.

##Documentation Was Part of the Attack#

I documented the engagement continuously rather than trying to reconstruct it after the exam. Every important step, result, and transition in the attack chain was recorded while it was fresh.

This served two purposes. First, it prevented knowledge loss across a long session involving multiple systems. Second, it reduced risk during reporting. The exam guide requires a detailed, reproducible report covering the attacks, commands, supporting output, and screenshots. Documentation is therefore not administrative work added after the technical portion; it is part of the exam itself.

My approach was to treat the notes as a live source of truth shared between me and the AI assistant. If a claim was not supported by direct evidence, it remained an assumption. If an action failed, the failure and its interpretation were recorded. If context moved to another model, the handoff was written from those records rather than from memory.

##How Useful Were My Previous OffSec Certifications?#

Each certification contributed differently:

• OSCP: Valuable. The enumeration mindset and familiarity with exploiting public vulnerabilities were directly useful.
• OSWE: Not a necessary prerequisite for OSAI. Intermediate web-security knowledge should be sufficient, although deeper source-code experience never hurts.
• OSEP: Also not a direct prerequisite. However, candidates should be comfortable with post-exploitation and moving through a multi-host environment.

The ideal starting point is therefore not advanced AI expertise. It is a reliable penetration-testing foundation combined with the willingness to learn how AI components alter a system's attack surface.

##Recommendations for Future Candidates#

My advice is straightforward:

1. Complete the course rather than relying on AI-generated summaries. The progression matters, particularly if AI security is new to you.
2. Do the labs. Understanding a concept intellectually is different from recognizing it inside a working environment.
3. Build an engagement methodology, not just a technique list. Maintain an address map, a validated credential ledger, a chronological log, and a list of disproven paths.
4. Use AI actively, but verify everything. Treat it as a capable collaborator that still requires scope, evidence, correction, and direction.
5. Preserve context deliberately. Ask for structured handoffs when changing assistants, and remind the active assistant to maintain durable notes after compaction.
6. Re-enumerate when stuck. An unexpected result often means an earlier assumption was wrong.
7. Take breaks. A fresh look can be worth more than another hour inside the same rabbit hole.
8. Document as you go. Do not leave the attack narrative and evidence collection until the end.

##Final Verdict#

Would I recommend AI-300? Yes, with one caveat: bring your penetration-testing fundamentals with you. The course spends its time on what changes when AI enters a system rather than re-teaching enumeration and exploitation. That focus is why four weeks was enough for me, and why I would point someone newer toward OSCP first.

The parts I expected to value were the AI-specific ones. The part I still use is the engagement methodology I built while working through the labs: the address map, the credential ledger, the record of what I had already ruled out. That is what kept me moving whenever a path stalled, and it applies just as well to a conventional engagement.