Organizations are rapidly deploying AI agents that can access enterprise data, invoke tools, and execute actions across business systems. Many of these deployments rely on the Model Context Protocol (MCP). While MCP accelerates agent capabilities, it also introduces new attack surfaces that security teams must evaluate before large-scale adoption.

The Securing the Model Context Protocol Summit is designed for security professionals responsible for assessing, approving, and defending AI agent deployments. Attendees will gain practical guidance from OWASP contributors, security researchers, and practitioners actively working to define secure MCP adoption patterns.

Read the agenda and get your tickets!

For Cyber_AI and _secpro subscribers, there is currently a 30% discount too. Make sure you don’t miss out—and see you there!

The Cyber_AI team is not associated with or otherwise gainfully connected to the developers of Augustus or any other piece of software mentioned in this article. This is a recommendation that comes from our own playing around in the office testing and reflection, with the intention that this should help our readers to deal with the modern challenges of AI security.

AI security testing can become complicated quickly. There are frameworks to configure, attack libraries to understand, models to connect and results to interpret. That can make it tempting to start with a huge red-team exercise before you have established whether your application can withstand basic attacks.

Augustus takes a more straightforward approach. It is a Go-based LLM vulnerability scanner from Praetorian that can run more than 210 adversarial probes against supported models and endpoints. It covers prompt injection, jailbreaks, data extraction, encoding attacks, RAG poisoning, agent attacks and other vulnerability classes. It also supports 28 provider categories and can test custom REST endpoints.

AI is reshaping quant trading, investment research, risk analytics, fintech infrastructure, and corporate decision systems. This 4-day intensive certification is designed for practitioners who want to build production-grade financial AI agents, not toy prototypes. Design and deploy a portfolio-grade Financial AI Agent architecture for trading, research, and enterprise finance workflows. Work directly with market data, SEC filings, earnings transcripts, etc.; master agentic system design; build applied systems for portfolio analytics, investment research automation, and corporate financial intelligence; and, earn a Packt-endorsed Agentic AI for Finance Certification to validate your applied AI skillset.

If you’re aiming to transition into AI-driven finance roles, quant-adjacent engineering, or applied LLM systems in enterprise environments, this is a high-signal, hands-on program.

Reserve your seat

1. Install Augustus and map out what it can test

The first advantage of Augustus is that it is distributed as a single Go binary. The current project requires Go 1.25.3 or later, and installation can be done with:

go install github.com/praetorian-inc/augustus/cmd/augustus@latest

Alternatively, clone the repository and build it locally.

Before pointing it at a production application, run:

augustus list

This is an important step because Augustus has a fairly large collection of probes, detectors, generators, harnesses and transformations. The list command lets you see the names actually registered in your installation rather than guessing them from documentation.

The basic architecture is worth understanding. A probe generates an adversarial test, a generator sends it to the target model, and a detector evaluates the response. Optional “buffs” transform the attack, for example through encoding or paraphrasing. The result is then recorded as a finding or pass.

You should also decide what you are actually testing. A foundation model accessed directly through an API is one target. A RAG application, internal chatbot or autonomous agent is another. Augustus can test all of these, but the most useful probes will differ.

2. Start with one controlled probe

Do not begin with --all.

Your first objective should be proving that Augustus can communicate correctly with your target and that you understand what its output means.

For example, with an OpenAI-compatible configuration, the project documentation demonstrates a basic jailbreak test:

export OPENAI_API_KEY="your-api-key"

augustus scan openai.OpenAI \
  --probe dan.Dan_11_0 \
  --detector dan.DAN \
  --verbose

The result gives you a compact view of the probe, detector, score and status. A vulnerable result means the detector identified behaviour matching the relevant attack condition.

This first scan is deliberately narrow. If it fails, you have a manageable troubleshooting problem. If you start with hundreds of probes and something goes wrong, you have a much harder problem to diagnose.

It is also worth remembering that a scanner result is not automatically a confirmed security vulnerability. Automated detectors have limitations. A response can trigger a detector without representing a meaningful application-level compromise, while a sophisticated attack can evade a detector.

Treat the first scan as a connectivity and baseline exercise.

3. Expand testing by attack category

Once the basic test works, expand gradually.

Augustus supports glob patterns, so you can select related probe families without specifying every probe individually. For example:

augustus scan openai.OpenAI \
  --probes-glob "dan.*,goodside.*,grandma.*" \
  --detectors-glob "*" \
  --output batch-results.jsonl

You can also run the complete probe collection:

augustus scan openai.OpenAI \
  --all \
  --config '{"model":"gpt-4"}' \
  --timeout 60m \
  --output comprehensive-scan.jsonl \
  --html comprehensive-report.html

Augustus currently groups its probes across 47 attack categories. These include jailbreaks, prompt injection, multi-turn attacks, data extraction, context manipulation, format exploits, evasion techniques, and so on.

That range is more useful than simply having a large number of attacks. It lets you start thinking in terms of an application’s threat model. For example, a customer-facing chatbot might justify substantial jailbreak and prompt-injection testing. A RAG application should receive more attention around context manipulation and knowledge-base poisoning. An agent with browser or API access introduces a different set of concerns.

The goal is not to maximise the number of failed probes, but, rather, to identify which classes of attack matter to your particular application.

4. Test the application, not just the underlying model

Testing a model directly tells you something about the model, but that doesn’t necessarily mean your AI application is secure. Augustus supports custom REST endpoints, which means you can put your own application in the testing path. The REST generator allows you to specify the endpoint, HTTP method, headers, request template and response field.

A simplified configuration looks like this:

augustus scan rest.Rest \
  --probe dan.Dan_11_0 \
  --detector dan.DAN \
  --config '{
    "uri": "https://api.example.com/v1/chat/completions",
    "method": "POST",
    "headers": {
      "Authorization": "Bearer YOUR_API_KEY"
    },
    "req_template_json_object": {
      "model": "custom-model",
      "messages": [
        {"role": "user", "content": "$INPUT"}
      ]
    },
    "response_json": true,
    "response_json_field": "$.choices[0].message.content"
  }'

This changes the value of the exercise. You are now testing the system users actually interact with, including its prompts, middleware and response handling. You can also send the traffic through an HTTP proxy such as Burp Suite or mitmproxy. That gives security engineers an opportunity to inspect requests and responses while Augustus performs the attacks.

Obviously, make sure this testing is authorised. Augustus deliberately sends adversarial prompts to its target, which means that some probes generate offensive content. The project explicitly recommends using it only against systems you own or are authorised to test.

5. Turn the results into a repeatable security test

A security team should not simply run a scan, find three failures and move on. Saving the results and establishing a baseline is also critical to increasingly sophisticated approaches. Augustus supports table, JSON, JSONL and HTML output. JSONL is particularly useful for integrating results into other tooling, while HTML is useful when sharing an assessment with people who do not want to read terminal output.

You can then repeat the same tests after changing a system prompt, guardrail, model, retrieval system or application control. This is particularly important because LLM security is not static. Changing the model can alter attack behaviour. Changing a system prompt can fix one jailbreak while introducing another weakness. Adding a tool can create a new attack surface. A regression test therefore has more value than a single point-in-time assessment.

Augustus also supports concurrency controls, retries and timeouts, which make it practical to incorporate into a more regular testing process. The default concurrency is 10 probes, but this can be adjusted with --concurrency. The best starting workflow is therefore quite simple: install Augustus, run one probe, expand into relevant attack families, move the scanner in front of the actual application and save the results as a baseline.

From there, Augustus becomes less of a novelty scanner and more of an automated security test harness. That is the useful way to approach it. Do not ask whether Augustus can “secure your LLM”. Ask which assumptions about your AI application it can test, which failures it can reproduce and whether those failures disappear when you make a security change. That produces results a security team can actually work with.