EresusSecurity
Model Security

Prove whether a model artifact is safe enough for production intake.

Eresus reviews pickle, PyTorch, ONNX, safetensors, GGUF, archive, and container artifacts from HuggingFace and private model repositories for supply-chain and runtime risk.

Best fit

This engagement creates value fastest for teams like these.

AI product and platform teams

Teams shipping LLM, RAG, MCP, agent, or model-intake workflows into internal or customer-facing environments.

Security leaders expanding into AI

Organizations that already run pentest programs and now need guardrail, prompt, and tool-abuse validation.

Teams that need explainable hardening

Groups that need policy, prompt, MCP, and runtime findings translated into concrete mitigations and release decisions.

Scope

Model artifact and archive intake
Pickle/PyTorch loading and code execution risk
ONNX external data and custom operator checks
AIBOM, hash, signature, license, and provenance

Risk signals

Code execution during model loading
External data paths escaping the model directory
Mutable artifacts caused by missing hash or signature
Secrets in model cards, notebooks, or config

Outcomes

Model intake risk report
Sentinel rule ID and evidence output
AIBOM and supply-chain checklist
CI/CD model intake gate recommendations
Model intake flow

Review model artifacts as executable supply chain, not passive files.

01

Problem

We identify where the model came from, how it loads, and where it will run.

02

Attack scenario

We test malicious pickle, custom operators, archive traversal, secrets, and dependency chains.

03

Proof

Evidence is tied to file paths, hashes, opcodes, AST nodes, manifests, or model metadata.

04

Delivery

Intake criteria, quarantine, signing, and retest steps are turned into release decisions.

FAQ

The questions buyers want answered early.

What AI surfaces and architectures do you test?+
We test autonomous AI agents, LLM integrations, RAG semantic search pipelines, MCP servers, tool execution boundaries, serialized model files (.pkl, .joblib, .gguf, .onnx, .keras), and guardrail implementations.
Is this limited to simple prompt injection testing?+
No. While prompt injection is evaluated, our red team focuses on systemic abuse: privilege escalation via tool use, indirect injection from retrieved documents, model extraction, training data poisoning, and remote code execution via unsafe model deserialization.
How are findings translated into engineering actions for AI teams?+
We map each vulnerability to specific defensive guardrail rules, system prompt structural hardening, strict JSON schema validators for tool calling, context window isolation, or container sandboxing configurations.
What is the duration and pricing for an AI Security Assessment?+
Typical AI and agentic security assessments take between 7 to 20 business days based on agent tooling count, RAG datasource complexity, and custom model architectures. Pricing is scoped transparently per integration boundary.
Do you assess compliance with the EU AI Act and OWASP LLM Top 10?+
Yes. All tests evaluate the full OWASP Top 10 for LLM Applications and provide risk categorization mapped against EU AI Act high-risk system transparency and cybersecurity requirements.
Is retesting included for AI guardrail and prompt fixes?+
Yes. We re-run targeted adversarial jailbreak suites and tool boundary validation within 30 days to ensure patched guardrails cannot be bypassed with semantic permutations.

We tie risk to business impact.

Findings do not stop at severity labels. We explain which customer workflow, data class, or operational objective is affected.

Deliverables work for engineers and executives.

Engineering teams get reproducible proof and remediation direction; leadership gets the risk narrative, priority, and closure status.

Next step

Let’s scope this work against the surface that matters most.

Whether this starts as a pilot, a single application, a critical API, an AI agent flow, or a wider program, we start from the highest-impact surface.