Security & Governance
On-Premise AI Agent Security: A Zero Trust Checklist
By Talentys · · 10 min read
Your CISO approved the AI agent pilot on one condition: it runs on-premises, inside your perimeter, where the data stays. That decision removes a whole category of risk — and creates a dangerous illusion. An agent on your network with a service-account credential and no controls is not "secure by proximity." Zero Trust was built for exactly this situation: never trust, always verify, assume breach. Here is the 12-point checklist we apply to every ArcaX deployment, organized in five layers.
Layer 1 — Identity: agents are principals, not users
Every security failure with agents traces back to identity. If your agents share a service account, you have already lost attribution, revocation, and least privilege — the three things auditors ask for first.
- 1. Per-agent identity. Each agent gets its own credential — ideally an mTLS certificate from your PKI, not a bearer token in an environment variable. Mutual TLS 1.3 gives you authenticated identity on every hop, with short-lived certificates (one hour is a good default) so a leaked credential expires before it can be abused.
- 2. No shared service accounts. Shared accounts make "who did this?" unanswerable. An agent that queries payroll and an agent that reads public documentation must be distinguishable in every audit record.
- 3. Scoped, expiring tokens. Any token the agent holds is short-lived, audience-restricted, and revocable in seconds — with CRL/OCSP-style revocation checked on every handshake, not once at login.
Layer 2 — Posture: is this agent healthy enough to act?
Authentication proves who is calling. Posture answers a harder question: should this identity be trusted right now?
- 4. Continuous posture scoring. Evaluate runtime signals — patch level, process integrity, anomaly flags — into a per-agent score on every call, not once per session. A compromised agent should lose access mid-flight, not at next login.
- 5. Quarantine as a state machine. When posture collapses, the agent moves to a quarantine state: calls denied, SOC alerted, human review required. Quarantine must be automatic — humans discover the incident from the dashboard, not by triaging tickets.
Layer 3 — Behavior: know what normal looks like
- 6. Behavioral baselines. Record each agent's normal call patterns (tools, volumes, arguments, hours) over a rolling window — seven days is a practical start. Deviation scoring against that baseline turns "something looks off" into a measurable threshold.
- 7. Automatic containment. Set an explicit deviation threshold (75% is the value we ship) that triggers the same quarantine FSM as posture failures. The goal is minutes from anomaly to containment, without a human in the loop for the stop decision.
- 8. Attack-matrix mapping. Map detections to MITRE ATT&CK and ATLAS so your SOC can reason about agent incidents with the same vocabulary it uses for human threats.
Layer 4 — Injection defense: the input you didn't write
Prompt injection is the defining agent risk: an attacker hides instructions in content the agent reads — a web page, a ticket, an email — and the agent executes them. No filter is fully reliable, so the answer is depth:
- 9. Treat retrieved content as untrusted. Sanitize everything that enters the context window: strip instruction-like patterns, isolate documents from system prompts, and never let retrieved text re-authorize itself.
- 10. Scan tool arguments, not just prompts. SQL injection, path traversal, SSRF and JNDI patterns belong in argument-level scanning on the gateway — with PII redaction applied before results reach the model.
- 11. Fail closed, outside the model. Policy enforcement (OPA or equivalent) happens at the gateway, deterministically, on every call. A policy that lives in the system prompt is a suggestion; a policy the model cannot see or rewrite is a control.
Layer 5 — Evidence: audit an auditor would accept
- 12. Tamper-evident, per-call audit. Every tool call recorded with the authenticated identity, the policy decision, arguments and result summary, and a timestamp — hash-chained (SHA-256, append-only, no DELETE) and sealed in batches a regulator can verify offline. Plain log files are not evidence; a sealed chain is.
Two operational rules make the chain usable: per-session circuit breakers (max tool calls, repeated-identical-call limits, wall-clock and token budgets, one-click emergency stop) limit blast radius while the chain records what happened; and shadow governance — evaluating candidate policies against live traffic before enforcing them — keeps the rule set honest without production roulette.
The one-page scorecard
| Layer | Controls | Audit question it answers |
|---|---|---|
| Identity | Per-agent mTLS, no shared accounts, short-lived revocable tokens | "Who — exactly — performed this action?" |
| Posture | Per-call scoring, automatic quarantine FSM | "Why was this agent trusted at that moment?" |
| Behavior | Baselines, deviation thresholds, ATT&CK mapping | "How did you detect and contain the anomaly?" |
| Injection defense | Input sanitization, argument scanning, fail-closed policy | "What stops a malicious document from acting?" |
| Evidence | Hash-chained per-call audit, circuit breakers, shadow governance | "Prove nothing was altered after the fact." |
None of this requires a cloud control plane. Every control above runs fully on-premises — including air-gapped — which is precisely the environments where agent governance is hardest and matters most.
Frequently asked questions
Is on-premise really safer than cloud for AI agents?
It removes data-egress risk, but not agent-specific risk: identity spoofing, prompt injection, uncontrolled tool access. On-premise plus Zero Trust controls is the strong combination — on-premise alone is not.
What is the most common agent security failure?
Treating agents as trusted users behind a shared service account. You lose attribution, revocation, and least privilege at once. Per-agent mTLS identity is the fix.
How do you defend against prompt injection?
Defense in depth: sanitize retrieved content as untrusted, scan tool arguments for injection/SSRF patterns, enforce policy fail-closed at the gateway, and scope tools so a successful injection can only reach what the tool already allows.
What audit evidence do regulators accept?
An append-only, hash-chained record per call: authenticated identity, policy decision, arguments, result, timestamp. WORM-compatible sealed chains meet the bar; plain log files don't.
Where do I start if agents are already in production?
Visibility first: put a gateway in observe mode, baseline real tool traffic, then close gaps in order — identity, scopes, injection filtering, circuit breakers — enforcing policy by policy.
Next steps
This checklist maps one-to-one to the five security layers ArcaX implements out of the box — including the per-call audit chain, the agentic circuit breaker, and shadow OPA governance. Use it as the requirements list for any agent deployment, ours or not; the questions an auditor will ask don't change with the vendor.
Related reading: vendor evaluation guide · MCP Gateway vs. MuleSoft · all ArcaX insights · compliance architecture