AI security: protect models, data and agents in production

SEYA Group's AI security consulting helps Canadian enterprises deploy LLM applications and AI agents without exposing data or systems: we assess prompt-injection and data-leakage risk, design controls, and monitor models in production. Typical engagements run four to twelve weeks and are led by senior security engineers from our Vancouver office.

Who this is for

CISOs and security architects whose teams are about to put a large language model, a retrieval system, or an agent in front of employees or customers. CIOs who have been asked to approve an AI feature and do not yet have a written view of what the model can reach. Engineering leads who already ship on AWS, Microsoft Azure, or Google Cloud and want the security work done by people who also read the pipeline.

This is a consultancy engagement. SEYA does not sell a model, does not operate a security operations centre, and does not certify that a system is safe or compliant. Findings are what the review and the agreed checks report.

Threats the review covers

The review uses two public references as its checklist, not as a badge. The OWASP Top 10 for LLM Applications names the failure modes that show up in deployed assistants: prompt injection, sensitive information disclosure, supply-chain weaknesses in models and plugins, and insecure plugin or tool use. The NIST AI Risk Management Framework is the structure we use to write the risk down so a security committee can read it: govern, map, measure, manage.

• Prompt injection. Instructions hidden in a document, a web page, an email, or a user message that try to override the system prompt or the tool policy.
• Data leakage. Training data, retrieval indexes, prompts, and tool outputs that can return customer data, secrets, or another tenant's content to the wrong caller.
• Model supply chain. Weights, containers, plugins, and evaluation sets that enter the environment without a record of origin, version, or the checks that ran before promotion.
• Agent tool abuse. An agent that can call internal APIs, tickets, or cloud accounts with a privilege broader than the person who asked the question.

What you get

• A written assessment. The systems in scope, the data they can reach, the identities they run as, and a ranked list of findings. Each finding says what was observed and what change we recommend. It does not say the system is certified.
• A control design. Input filtering, output checks, tool allow-lists, secret handling, and logging, mapped to the pipeline and cloud accounts you already use. Where you want the controls built, that build is a separate, agreed scope and sits beside DevSecOps work so the checks run on every change.
• A monitoring plan. What to log (prompts are often sensitive; the plan says what must not be stored), which alerts are worth paging a person for, and who reviews them.
• A handover pack. The assessment, the control list, and a working session with your security and engineering owners. You keep the documents and the accounts.

How an engagement runs

• Scoping call. You name the application, who uses it, which data it can retrieve, and which tools it can call. We say whether the first piece of work is an assessment, a control design, or both.
• Assessment. We read the architecture, the identity model, and a sample of prompts and tool traces with your engineers. We do not need production customer data copied to SEYA.
• Controls. We write the control design against the findings. Your owners decide what blocks a release. SEYA recommends; the exception process stays yours.
• Monitoring. Logging and review are agreed before any agent is given a new tool. If the application is not in production yet, this step is a design, not a live feed.
• Handover. Your team leaves with the documents and, where a build was in scope, the pipeline checks. A later review can repeat the same baseline after the system changes.

What you need in place

A security owner and an engineering owner, a description of the model or agent, and access to the design and the non-production environment. If the model itself is still being built, that build is a product engagement. SEYA reviews how it is deployed and what it is allowed to touch. If the open question is policy and evidence for a committee, start with AI governance. If you want the prompts and tools attacked on a clock before launch, start with an LLM security assessment.

Out of scope: a guarantee that a model cannot be misled, a claim that SEYA or your system is certified to NIST, ISO, or any other standard, and a managed detection service. Published proof of how SEYA handles a client's security review is the Boeing GoldCare move to Azure, where the infrastructure was vetted by Boeing InfoSec before workloads went live. That engagement was a cloud migration with a security gate, not an LLM deployment. We cite it because the review pattern is the same: the client's security team sees the design before production.

Questions buyers ask

Do you certify our AI system?

No. SEYA writes findings, a control design, and the evidence those controls produce. A certification, if you want one, is between you and the body that issues it. We will not put a certification mark on the report.

How long does an AI security engagement take?

A first assessment of one application is often inside four to twelve weeks, depending on how many tools the agent can call and how much of the design is written down already. A multi-product programme is scoped as phases, not as one open-ended review.

Will you train or host the model?

No. The engagement covers how the model or agent is reached, what data it can see, and which actions it can take. Building the product is a separate decision and is not part of this service.

Which clouds does the review assume?

AWS, Microsoft Azure, and Google Cloud, because that is where SEYA's delivery work already runs. The threat list is the same if the model is called as an API. The control design follows the identity and logging tools your platform already has.

If an LLM feature is close to launch and the security review is still a slide, book a cloud security assessment and we will say what the first four weeks would cover.