LLM security assessment and red teaming

SEYA Group's LLM security assessment is a fixed-scope red team of one language-model feature: we test the prompts, the tools the model can call, and the data paths those tools can reach, then write a report your security and engineering owners can act on. A typical assessment runs two to four weeks and is led from our Vancouver office. It is a test and a report, not a certification.

Who this is for

Security and product owners who have a launch date for a chatbot, a retrieval assistant, or an internal agent, and who need an independent pass before that date. Teams that already ran a vendor questionnaire and still cannot say what happens if a user, or a document the model reads, tells the model to ignore its instructions.

What you get

• A scope note. The feature, the environments, the identities, the tools in play, and what is out of scope. Production customer data is not copied to SEYA.
• A test method. Cases drawn from the OWASP Top 10 for LLM Applications: direct and indirect prompt injection, attempts to extract secrets or other users' content, tool calls outside the allow-list, and poisoned or unexpected content in the retrieval index. We record each case, the input, and the observed behaviour.
• A report. Findings ranked by what the model was able to do, with the evidence attached, and a short list of control changes. The report does not say the feature is safe in general. It says what these tests did and did not achieve.
• A readout. One working session with your security and engineering owners. Fixes you choose to build can continue as AI security control design or as DevSecOps checks in the pipeline.

How an engagement runs

• Week 0, scoping. Access to a non-production build, the system prompt or policy you are willing to share, and the list of tools.
• Weeks 1 to 3, testing. We run the cases, adjust them when a control blocks the obvious form of the attack, and stop at the scope boundary. We do not attack systems that were not named.
• Final week, report and readout. You receive the written report and the session. Two to four weeks is the usual range for one feature. A second product is a second scope.

What you need in place

A build we can call, an owner who can explain the intended tool policy, and agreement that findings will be written plainly. If you do not yet have a policy for what the assistant is allowed to do, the governance questions belong on the AI governance page and can run before or beside this test.

Out of scope: training a model, a promise that a later prompt will not succeed, and any statement that SEYA or the feature holds a security certification. For an example of a client security review on SEYA work, see the Boeing InfoSec review of the Azure infrastructure for GoldCare. That review was of a cloud platform, not of an LLM. We cite it only as the pattern: the client's security team sees evidence before go-live.

Questions buyers ask

Is this a penetration test of our whole company?

No. The scope is the LLM feature you name: its prompts, tools, and data paths. Network penetration testing of the wider estate is a different engagement and is not bundled into these two to four weeks.

What does the report look like?

A scope statement, the test cases, what each case did, and recommended control changes. It is written for a security owner and an engineering owner. It is not an attestation letter and it has no certification mark.

Can you retest after we fix the findings?

Yes, as a short follow-up against the same cases, scoped separately. The first report stays the baseline. A pass on the retest means those cases no longer succeeded, not that the feature is safe against every future prompt.

If a launch date is already on the calendar, book a cloud security assessment and send the feature description. We will say whether two to four weeks is enough for that scope.