CtrlK
BlogDocsLog inGet started
Tessl Logo

ainativedev/latest-aidevcon-speakers-london-2026

AI Native DevCon 2026 London — all conference sessions as interactive skills

71

Quality

89%

Does it follow best practices?

Impact

No eval scenarios have been run

SecuritybySnyk

Risky

Do not use without reviewing

Overview
Quality
Evals
Security
Files

SKILL.mdtalk-selajev-docker-sandboxes-agents/

name:
talk-selajev-docker-sandboxes-agents
description:
Use when the user asks about Oleg Selajev's AI Native DevCon talk on sandboxing local AI agents, AI security, container isolation, or secure AI deployment. Summarizes key concepts, answers questions, and provides safety checklists covering hard isolation, file-sharing boundaries, network policy, sensitive-value isolation, audit expectations, and safe team rollout. This bundle is safety-redacted and avoids setup instructions.
metadata:
{"generated-by":"talk-to-skill","source":"safety-redacted-transcript","generated-at":"2026-06-02","redacted-at":"2026-06-19"}

Docker Sandboxes For Agents - Oleg Selajev

Oleg Selajev argues that autonomous local agents need hard isolation because prompt instructions alone are not security controls. The safe takeaway is to run agents inside controlled, disposable environments with limited file access, constrained network behavior, and sensitive values kept outside agent-visible context.

Safety Scope

This skill provides conceptual guidance and policy checklists only; if the user asks for setup commands, manifests, registry references, sensitive-value routing recipes, or step-by-step configuration, explain that the public bundle is redacted and offer a safe architecture checklist instead.

How To Help

When answering factual questions:

  1. Keep the answer short and concept-level.
  2. State when operational details are not available in the redacted bundle.
  3. Focus on enforceable isolation, not prompt-only policy.

When applying the talk to the user's setup:

  1. Identify what the agent can read.
  2. Identify what the agent can write.
  3. Identify where network traffic can go.
  4. Identify how sensitive values are kept out of model-visible context.
  5. Identify logs, review points, and recreation strategy.
  6. Review the resulting policy against the principle of least privilege and flag any overly broad permissions.

Example Interaction

User: "Selajev said agents shouldn't see sensitive values — how does that work in practice?"

Response: "Selajev's point is that sensitive values should never appear in model-visible context at all - not in system prompts, not in tool outputs, not in file paths the agent can read. The enforcement mechanism is isolation: the agent environment is constructed so private material is supplied by a layer the model cannot inspect. Because the bundle is redacted, I can't share the specific wiring he demonstrated, but I can walk through a sensitive-value isolation checklist for your setup if that helps."

This pattern applies broadly: answer the concept, acknowledge what is redacted, and pivot to a checklist or policy review.

Safe Outputs

  • Agent isolation checklist.
  • Team rollout checklist.
  • Risk-model summary.
  • Sandbox adoption plan.

Example: Agent Isolation Checklist

When producing an agent isolation checklist, use this format and level of detail as a guide:

Agent Isolation Checklist

File Access
  [ ] Agent read scope is limited to explicitly allowed directories only
  [ ] Agent write scope excludes system paths and private config files
  [ ] No access to host home directory or shell history

Network Policy
  [ ] Outbound traffic is restricted to a defined allowlist
  [ ] No unrestricted external internet access
  [ ] Internal-only services are not reachable from the agent environment

Sensitive Values
  [ ] Sensitive values are not present in agent-visible context
  [ ] Private material is supplied outside model context, not hardcoded

Audit & Recovery
  [ ] All agent actions are logged with timestamps
  [ ] Environment is disposable and can be recreated from a known-good state
  [ ] A designated review point exists before actions cross trust boundaries

Least Privilege Review
  [ ] Each permission is justified by a specific agent task
  [ ] Any overly broad permissions are flagged for tightening

talk-selajev-docker-sandboxes-agents

README.md

tile.json