The value of an AI model does not stop at training. Inference, the moment a model makes a decision, can
expose its logic, leak sensitive data, and create a path for theft. Most organisations focus on training data
security but leave inference endpoints open. The result: intellectual property loss, regulatory exposure, and
diminished competitive advantage.
Model extraction attacks, where an external party queries a deployed model to reverse-engineer it, are now
a credible threat. These attacks often go unnoticed until a competitor’s clone emerges or data leakage occurs.
Boards and CISOs should treat this as a material business risk.
This briefing outlines the key issues and gives security leaders the right questions to ask their teams.
Why Inference Is an Attack Surface
Every time your AI model answers a request - whether in an app, dashboard, or partner integration - it reveals
something. A determined attacker can collect enough inputs and outputs to train a replica of your model.
This type of attack, known as model extraction, requires no breach. It only needs a live API and enough time.
Inference security matters because:
- Your model is IP. If someone copies it, they copy your advantage.
- Output data may be sensitive. A misstep could violate privacy rules.
- LLMs and AI agents often trigger downstream actions. A compromised model can lead to real-world harm.

What Makes This a Board-Level Concern
- Theft of Investment
Training a model may cost millions. Allowing it to be cloned through a public endpoint undermines the
entire R&D effort.
- Compliance Risk
If your model exposes decisions about individuals - such as credit, medical risk, or eligibility - then misuse of
the inference layer could breach data protection laws. - Loss of Trust
If your AI-driven product behaves unpredictably, customers may lose confidence, not just in the model, but in
your company’s competence and safety standards.

Questions Cybersecurity Leaders Should Be Asking
Cybersecurity Leaders should review inference exposure now. Key questions include:
- Are inference endpoints publicly accessible, and if so, are they rate-limited?
- Do we log and analyse input-output patterns for abnormal use?
- Can our models return full probability scores, or are responses obfuscated?
- Have we tested our models for extractability?
- Can attackers train a clone using outputs from our model APIs?
Is our model watermarking or tamper-resistant?
These questions are not theoretical. Attack techniques exist, and tooling to conduct and defend against model
extraction is advancing rapidly.

What Cybersecurity Teams Should Be Doing
- Restrict access to inference endpoints where possible. Use API gateways, tokens, and tenant isolation.
- Limit output detail. Return only class labels or rounded scores where exact probabilities are unnecessary.
- Detect misuse. Log high-volume queries, unusual input patterns, or entropy spikes.
- Use watermarking to trace model leakage. Even if extraction occurs, this provides evidence.
- Integrate inference protection into your secure development lifecycle. This is not just a deployment concern.
It must be designed in.
Closing Thoughts
Model inference security is no longer niche. It is now a real, exploitable gap in many cloud AI deployments. If your
model is valuable, someone will try to copy it. If it makes decisions, someone may try to manipulate or expose them.
CISOs should bring this to the board, not after a breach, but now, while there is time to act. Protecting your model
at inference is not a theoretical defence. It’s table stakes for anyone deploying AI in production.
Related Resources
Find your Tribe
Membership is by approval only. We'll review your LinkedIn to make sure the Tribe stays community focused, relevant and genuinely useful.
To join, you’ll need to meet these criteria:
> You are not a vendor, consultant, recruiter or salesperson
> You’re a practitioner inside a business (no consultancies)
> You’re based in Australia or New Zealand