Skip to content

S.H.I.E.L.D. security methodology

Secure-by-default · Harden boundaries · Isolate workloads · Encrypt at rest and transit · Log everything · Detect anomalies

S.H.I.E.L.D. is the standing security posture: the platform conditions under which AI-assisted development is safe to do at all. It is paired with S.E.C.U.R.E., which is per-change.

The premise of S.H.I.E.L.D. is that AI assistants will introduce mistakes (that is true even with disciplined V.E.R.I.F.Y. and S.E.C.U.R.E.), and the system should be built so those mistakes are contained rather than catastrophic.

Why containment, not prevention

The DeepSeek 2025 ClickHouse exposure1 and the Replit 2025 agentic-database deletion2 are not failures of people; they are failures of containment. A laptop agent that can rm-rf production is a system whose blast radius was set too wide. The posture matters more than the policy.

When does S.H.I.E.L.D. apply?

Continuously. S.H.I.E.L.D. is the operating environment for AI-assisted development, not a per-change checklist. New systems are designed to it; existing systems are migrated to it during Phase 2: Scale.

The most important shift S.H.I.E.L.D. requires is treating agentic tools (assistants that can execute commands, write files, or call APIs) as untrusted execution contexts by default, even on developer laptops.

The six parts

S. Secure-by-default

Defaults are the security stance the team will get on a Tuesday afternoon when nobody is paying attention. Set them well:

  • Default deny on network egress; allow-list specific destinations.
  • Default read-only on file systems and databases for any agentic tool; explicit grants for write paths.
  • Default no-shell for AI tools; if shell is needed, sandboxed.
  • Default short TTL on tokens, credentials, and exception grants.
  • Default opt-out of training on prompts and code, where the vendor exposes that switch.

If the default has to be overridden, the override is a Decision Record, not an unwritten norm.

H. Harden boundaries

Every place the AI assistant interacts with the rest of the system is a boundary that needs hardening:

  • Model endpoints. Allow-list the specific endpoints the team is approved to use (per the vendor standards). Block the rest at the egress proxy.
  • Prompt-injection defenses. Treat any text fetched from a third-party source (webpages, PDFs, issue bodies, chat transcripts) as adversarial input to the model. Filter, fence, and sanitize before passing to the model.
  • Tool-use guardrails. When an agent can call tools (shell, HTTP, file I/O), the tool layer enforces what the model is allowed to do. The model is the decider; the tool layer is the enforcer.
  • API gateways. Outbound calls from AI-generated code go through the same gateway as human-written code. No bypass paths.

The Chevy dealer chatbot prompt-injection3 is the canonical cautionary tale: an agent boundary that trusted user input as instructions. Boundary hardening is what stops this class of issue.

I. Isolate workloads

Containment is the central S.H.I.E.L.D. discipline:

  • Agentic tools run in sandboxes, not on developer laptops with shell access to the developer's home directory and SSH keys. Containers, VMs, ephemeral cloud workspaces, or constrained CLI shells: pick one.
  • Production credentials never reach a developer's AI tool. A laptop agent should not be able to assume a production role.
  • Secrets stores are isolated from the assistant's reach unless the assistant is acting on a path that explicitly needs them.
  • Blast radius is bounded. An agent should not be able to delete a database, exfiltrate a customer table, or push to main from a non-PR context.

A useful framing: if the agent were compromised tomorrow (its model poisoned, its provider breached, its prompt hijacked) what is the worst thing it could do with its current access? That is your blast radius. If the answer is unacceptable, isolate further.

E. Encrypt at rest and transit

The standard discipline applies, with two AI-specific notes:

  • Prompts and outputs in transit must be TLS-encrypted; verify the vendor uses modern TLS and confirm certificate pinning where appropriate.
  • Prompts and outputs at rest, wherever the team's tooling logs them, must be encrypted with key management equivalent to the team's source-code repository. Prompts can contain code, secrets, and customer data; treat them accordingly.
  • Secrets in prompts are a leak even when the channel is encrypted; encryption is not a substitute for not putting secrets there in the first place.

L. Log everything

For AI-assisted development, "everything" includes:

  • Prompts: who, when, which tool, which session, redacted content where required by AUP.
  • Outputs: what the model produced and what was accepted.
  • Tool calls: for agentic tools, every shell command, file write, HTTP call, and API invocation, with arguments.
  • Acceptance events: when a developer pulled an AI suggestion into a working file, what they pulled.
  • Egress: every outbound call to a model endpoint, with destination, principal, and byte counts.

Retention follows the audit trail policy. Regulated environments retain longer; small teams retain shorter but still retain.

D. Detect anomalies

Logs without detection are an archive, not a control:

  • Egress anomalies. A spike in outbound bytes to a model endpoint, especially after-hours or from a single principal, should page.
  • Prompt anomalies. A prompt containing a regex hit on a credential pattern or a customer-data pattern should fire an alert, even if the AUP would not have caught it.
  • Tool-use anomalies. An agent issuing a DELETE FROM users or rm -rf / (or anything close) should hard-stop, page, and require human re-authorization to continue. The Replit incident2 is the cautionary baseline.
  • Acceptance-rate anomalies. A developer who suddenly accepts 100% of suggestions, where they previously accepted 40%, has either changed practice or stopped reading. Either is worth knowing.

Detection is where S.H.I.E.L.D. closes the loop with incident response: a fired detection becomes a triaged incident.

How S.H.I.E.L.D. composes with S.E.C.U.R.E.

Property S.H.I.E.L.D. (standing) S.E.C.U.R.E. (per change)
Cadence Continuous Per diff
Owner Platform / Security Author + Reviewer
Output Hardened environment Verified change
Failure mode Blast radius Defect in production
Tied to Data handling, Vendor standards Risk classification, V.E.R.I.F.Y.

S.E.C.U.R.E. without S.H.I.E.L.D. is a checklist with no enforcement. S.H.I.E.L.D. without S.E.C.U.R.E. is a hardened environment that still ships defective code. Both, together.

Sizing guidance

Sizing guide

  • Small (< 50). Pick the highest-value control and run it: egress allow-listing on the model endpoint, sandboxed agentic tools (a devcontainer or equivalent), prompts not stored beyond the vendor's default retention. Skip the formal SOC if you don't have one.
  • Mid (50–500). All six steps, with a named owner per step. Detection runs through whichever observability stack already exists; do not buy a second one for AI events.
  • Enterprise (500+). S.H.I.E.L.D. is a program with a multi-quarter roadmap. Egress allow-listing, sandboxed agents, and tool-use logging are non-negotiable on day one. Anomaly detection follows in quarter two.
  • Regulated. S.H.I.E.L.D. is the control surface that maps to the regulatory crosswalk. ISO 27001 A.8, ISO 42001 clause 8, and EU AI Act Article 9 all have provisions that S.H.I.E.L.D. operationalizes.

Enforcement placement

Each S.H.I.E.L.D. control can be enforced at one or more of three layers. The choice is not aesthetic; a control placed at the wrong layer will appear to work and fail silently.

Layer Infrastructure Managed by Strengths Limitations
Endpoint Developer laptop, IDE plugin, devcontainer, git hook DevEx configures; CISO sets standard Low latency; no extra infrastructure; enables ergonomic nudges Drift-prone on unmanaged devices; circumventable; configuration is tool-specific
Network / platform Egress proxy, SSO gateway, DLP proxy, DNS filter Platform Security operates; CISO accountable Tool-agnostic; centrally managed; hard to circumvent for cloud traffic Requires infrastructure investment; may need TLS inspection for full DLP coverage; blind to local-only operations
Vendor Tool's enterprise admin console CoE (tool-admin role); CISO sets requirements Native to the tool; no extra infrastructure Control quality varies by vendor; vendor can change or remove controls without notice; requires per-tool re-validation

Placement decisions by control type

Control Preferred layer Rationale
Model endpoint allow-listing Network (egress proxy) Endpoint allow-listing is circumventable; proxy is authoritative for cloud-bound traffic
Data-class blocking (DLP on outbound prompts) Network (DLP proxy) Endpoint-side DLP is advisory; network-side is enforceable across all tools
Identity and provisioning Vendor + SSO gateway SAML/OIDC is the enforcement point; SCIM keeps the vendor roster current
Per-tool spend caps Vendor (billing console) Only the vendor has authoritative billing data; network monitoring is supplementary
Audit log export Vendor (admin console) Full fidelity only from the tool itself; proxy logs miss in-tool events
Training opt-out Vendor (account setting + contract) Contractual; only the vendor can honor it; network cannot enforce
Agent sandbox Endpoint (devcontainer or ephemeral VM) OS-level isolation requires host control; vendor or network cannot substitute
Secrets detection Both: endpoint (pre-commit hook) and network (outbound filter) Defense-in-depth; neither layer alone catches every path

The guiding principle: enforce at the highest-trust layer available for the control type, not the most convenient layer. Endpoint-only enforcement is appropriate only for controls where the threat is local (e.g., sandbox isolation). Network-layer enforcement is the default for controls aimed at preventing data from leaving the boundary. Vendor-layer enforcement is the default for controls that require billing or model-training authority.

Enforcement ownership

Every active control requires a named owner for each layer it spans. An owner is responsible for initial configuration, drift review, and updates when tools change.

Layer Configuration owner Standard owner Review trigger
Endpoint DevEx CISO Quarterly drift check; any tool addition
Network / platform Platform Security CISO Any tool addition; quarterly rule review
Vendor CoE (tool admin) CISO Each quarterly vendor review; any vendor admin-surface change

An orphaned control — one with no named configuration owner — is not a control. If nobody is accountable for reviewing whether the egress proxy rules are current, or whether the vendor's admin console settings survived the last product update, the control exists only on paper. Add enforcement ownership to the RACI.

Multi-tool enforcement consistency

When the approved stack includes two or more tools, the same control may exist natively in Tool A and be absent, partial, or placed at a different layer in Tool B. The gap is where incidents happen.

The minimum enforcement baseline

Before any tool enters the approved list, define a minimum enforcement baseline: the set of controls every tool must satisfy, through any layer combination. A tool that cannot satisfy a baseline control requires either a compensating control or a Decision Record explicitly accepting the residual risk.

Typical baseline requirements:

  • Identity: SSO via SAML or OIDC. No exceptions.
  • Provisioning: SCIM de-provisioning; termination events must revoke access within 24 hours.
  • Audit log export: structured export covering identity events, model selection, and session records.
  • Training opt-out: contractual, not a settings toggle the vendor can silently remove.
  • Network coverage: the tool's API endpoints are included in the egress proxy allow-list and DLP proxy scope from day one.

The per-tool enforcement matrix

Maintain a per-tool enforcement matrix — a single reference document showing which controls are enforced at which layer for each approved tool, and where gaps exist. The matrix is reviewed at each quarterly vendor review and updated whenever a tool's admin surface changes.

Example format:

Control Tool A Tool B Tool C
Model endpoint allow-listing Network proxy Network proxy Network proxy
DLP on outbound prompts Network proxy Network proxy Network proxy
Spend cap Vendor (hard cap) Vendor (alert only — DR #47, risk accepted until Q3) Network (monitoring only — compensating control)
Audit log export Vendor (full fidelity) Vendor (limited) + proxy supplement Vendor (full fidelity)
Training opt-out Vendor (contract) Vendor (contract) Vendor (contract)
Agent sandbox Endpoint (devcontainer) N/A (no agent mode) Endpoint (devcontainer)

A gap cell must reference either a compensating control or a DR. Blank cells are not permitted.

What the network layer cannot compensate

The network layer is the default compensating layer for missing vendor controls — but it is not a universal substitute:

  • Training opt-out: a vendor contractual term; cannot be enforced at the network proxy.
  • Spend hard caps: network-layer monitoring alerts on volume but cannot block individual spend; vendor-native caps are required for hard enforcement.
  • Agent sandbox: OS-level isolation; neither vendor nor network can substitute for an endpoint-level devcontainer.

When a compensating control is impossible, the gap is accepted risk. Accept it explicitly via DR — not by omission.

Additive drift: the failure mode to avoid

The most common multi-tool enforcement failure is additive drift: a new tool passes the vendor scorecard and security review, but nobody updates the egress proxy allow-list for the new tool's endpoints, nobody extends the DLP proxy scope, and nobody assigns a spend-cap admin in the new tool's billing console. Controls that apply to Tool A simply do not apply to Tool B, and this persists undetected until an incident surfaces the gap.

The fix is procedural: the tool onboarding workflow must include a mandatory enforcement-matrix update step that extends existing controls to the new tool's endpoints before the tool reaches full approval.

Anti-patterns

Don't

  • Don't run agentic tools with shell access on developer laptops without a sandbox boundary. The agent has the same reach as the developer's keyboard, and the developer's keyboard can do real damage.
  • Don't leave model endpoints un-allow-listed. A developer who can route prompts to any endpoint can route them to one that doesn't honor the AUP.
  • Don't log prompts in plaintext alongside customer data. Prompt logs are a high-value target; encrypt them and apply the same access controls as source code.
  • Don't treat S.H.I.E.L.D. as one-time hardening. Defaults drift, allow-lists rot, detections silence themselves. Quarterly review or it stops working.
  • Don't trust prompt-injection defenses you have not tested. Boundaries that have never been attacked are boundaries you do not know the strength of. Run red-team exercises.

Next

  1. Wiz Research, "Wiz Research Uncovers Exposed DeepSeek Database Leaking Sensitive Information, Including Chat History", Jan 2025. [primary] ↩

  2. Replit, "The Replit AI agent deletion incident: what happened and what we changed", Jul 2025. [primary, vendor self-reported] ↩↩

  3. Business Insider, "A Chevrolet dealership added an AI chatbot to its site. Then customers convinced it to sell them an SUV for $1.", Dec 2023. [secondary; multiple outlets reported] ↩