{
  "schemaVersion": 1,
  "id": "atlas-lesson-sandbox-egress-secrets",
  "title": "Execution boundaries for code and tools",
  "category": "learning",
  "format": "Atlas lesson",
  "description": "Filesystem, process, network and secret boundaries; authorization is checked at actual execution points.",
  "canonicalUrl": "https://semiaifoundry.com/learn/atlas/sandbox-egress-secrets/",
  "publishedDate": null,
  "revisionDate": "2026-10-07",
  "author": null,
  "topic": "Authority, context and execution boundaries",
  "series": null,
  "license": null,
  "rightsUrl": "https://semiaifoundry.com/ai-atlas/licenses.html",
  "version": "1.3.0",
  "status": "Published educational lesson",
  "evidenceScope": "This is a worked explanation, not an executing external platform, model or robot. The quantities and fixtures are authored. Source scope is recorded in the automation learning review manifest; no source benchmark or private system behavior is claimed. Payload-only ledger; excludes allocator overhead, runtime memory and operating-system state. One MiB is 2^20 bytes. No real sandbox or memory measurement is executed here.",
  "contentCoverage": "published-lesson",
  "artifactUrl": "https://semiaifoundry.com/ai-atlas/lesson-data/sandbox-egress-secrets-d95b556a68c180e2.json",
  "interactiveUrl": "https://semiaifoundry.com/ai-atlas/#sandbox-egress-secrets",
  "related": [],
  "supersedes": [],
  "supersededBy": [],
  "contentHash": "dbeedb1dd2da1224e1371b0772166479d87bd70348d1d596236bcbe871d3969c",
  "contentLength": 6350,
  "jsonUrl": "https://semiaifoundry.com/agents/publications/atlas-lesson-sandbox-egress-secrets.json",
  "markdownUrl": "https://semiaifoundry.com/agents/publications/atlas-lesson-sandbox-egress-secrets.md",
  "sections": [
    {
      "id": "section-1",
      "title": "Execution boundaries for code and tools",
      "start": 60,
      "end": 482
    },
    {
      "id": "section-2",
      "title": "The mechanism",
      "start": 482,
      "end": 1809
    },
    {
      "id": "section-3",
      "title": "Science and assumptions",
      "start": 1809,
      "end": 1837
    },
    {
      "id": "section-4",
      "title": "Execution boundaries for code and tools · explicit relationship",
      "start": 1837,
      "end": 2936
    },
    {
      "id": "section-5",
      "title": "Engineering example",
      "start": 2936,
      "end": 3523
    },
    {
      "id": "section-6",
      "title": "Distinctions and tradeoffs",
      "start": 3523,
      "end": 3894
    },
    {
      "id": "section-7",
      "title": "Specifications and interfaces",
      "start": 3894,
      "end": 4354
    },
    {
      "id": "section-8",
      "title": "Interfaces",
      "start": 4354,
      "end": 4615
    },
    {
      "id": "section-9",
      "title": "Check your understanding",
      "start": 4615,
      "end": 4644
    },
    {
      "id": "section-10",
      "title": "A 40 MiB input and 32 MiB output overlap under a 64 MiB limit. Does the live payload fit?",
      "start": 4644,
      "end": 5032
    },
    {
      "id": "section-11",
      "title": "Evidence and scope",
      "start": 5032,
      "end": 5615
    },
    {
      "id": "section-12",
      "title": "Sources",
      "start": 5615,
      "end": 6013
    },
    {
      "id": "section-13",
      "title": "Continue exploring",
      "start": 6013,
      "end": 6036
    },
    {
      "id": "section-14",
      "title": "Foundations",
      "start": 6036,
      "end": 6160
    },
    {
      "id": "section-15",
      "title": "Related lessons",
      "start": 6160,
      "end": 6350
    }
  ],
  "citations": [
    {
      "title": "Explore in Atlas",
      "url": "https://semiaifoundry.com/ai-atlas/#sandbox-egress-secrets"
    },
    {
      "title": "Linux man-pages · namespaces(7)",
      "url": "https://man7.org/linux/man-pages/man7/namespaces.7.html"
    },
    {
      "title": "Linux man-pages · seccomp(2)",
      "url": "https://man7.org/linux/man-pages/man2/seccomp.2.html"
    },
    {
      "title": "Published lesson data",
      "url": "https://semiaifoundry.com/ai-atlas/lesson-data/sandbox-egress-secrets-d95b556a68c180e2.json"
    },
    {
      "title": "Atlas releases and licensing",
      "url": "https://semiaifoundry.com/ai-atlas/licenses.html"
    },
    {
      "title": "User authority and service identity",
      "url": "https://semiaifoundry.com/learn/atlas/tool-authority-identity/"
    },
    {
      "title": "Tools, memory & agent loop",
      "url": "https://semiaifoundry.com/learn/atlas/tool-loop/"
    },
    {
      "title": "Evaluation & the AGI frontier",
      "url": "https://semiaifoundry.com/learn/atlas/evaluation/"
    }
  ],
  "recordHash": "6a9404fdeac90bc41f46fdf72615b16daf455d65f180ea61c80dc30a9eb4338a",
  "contentFormat": "text/markdown",
  "content": "Authority, context and execution boundaries · Atlas v1.3.0\n\n# Execution boundaries for code and tools\n\nFilesystem, process, network and secret boundaries; authorization is checked at actual execution points.\n\n[Explore in Atlas](https://semiaifoundry.com/ai-atlas/#sandbox-egress-secrets)Logical state, task evidence and declared units; no physical assembly scale\n\nLearning objectiveSeparate process containment, resource budgets and task correctness in a generated-code execution.\n\n## The mechanism\n\nA tool that executes code needs an operating-system boundary as well as an application permission check. A filesystem view, process identity, network access, system-call policy and resource limits constrain different behaviors. Linux namespaces isolate selected resource views; syscall filtering addresses another layer. Neither a container label nor a prompt establishes that every unwanted effect is impossible. A runner should grant only the files, endpoints and credentials needed for its declared task, report denied operations, and distinguish termination from successful completion. Secrets should not be copied into prompts or routine trace output. The incident experience has local capability checks but does not execute arbitrary code inside a Linux sandbox. The example below is a resource ledger and boundary analysis, not a claim that such isolation has been deployed.\n\n1.  The task defines the files, network endpoints and operations needed by the code runner.\n2.  Runtime enforcement applies those permissions where the process attempts the effect, independently of generated instructions.\n3.  Memory and time limits bound consumption; denied or killed execution returns a distinct result.\n4.  The exported evidence identifies the tested input and outputs while excluding credential material.\n\n## Science and assumptions\n\n### Execution boundaries for code and tools · explicit relationship\n\n$$\nB_{\\mathrm{peak}}=\\max_t\\sum_{i\\in\\mathcal L(t)}B_i\n$$\n\nPeak live payload is the maximum sum of buffers that coexist at the same time.\n\nSymbols and units\n\nBpeak\n\nPeak modeled live buffer payload\n\nMiB\n\n𝓛(t)\n\nBuffers live at time t\n\nbuffer set\n\nBᵢ\n\nPayload size of buffer i\n\nMiB\n\nA hypothetical runner has a 64 MiB memory limit. It retains a 40 MiB input buffer and allocates a 32 MiB output buffer before releasing the input, giving at least 72 MiB live payload. That schedule does not fit, even though neither buffer individually exceeds the limit. Streaming can reduce overlap if the algorithm permits it; relabeling the limit cannot. Separately, denying network egress prevents an unrelated outbound call but does not make a wrong local patch correct. Resource feasibility, effect containment and task evaluation remain different checks.\n\nAssumptions Payload-only ledger; excludes allocator overhead, runtime memory and operating-system state. One MiB is 2^20 bytes. No real sandbox or memory measurement is executed here.\n\n## Engineering example\n\nA hypothetical runner has a 64 MiB memory limit. It retains a 40 MiB input buffer and allocates a 32 MiB output buffer before releasing the input, giving at least 72 MiB live payload. That schedule does not fit, even though neither buffer individually exceeds the limit. Streaming can reduce overlap if the algorithm permits it; relabeling the limit cannot. Separately, denying network egress prevents an unrelated outbound call but does not make a wrong local patch correct. Resource feasibility, effect containment and task evaluation remain different checks.\n\n## Distinctions and tradeoffs\n\nA sandbox label or a model instruction is not a complete, tested execution boundary.\n\nTighter restrictions reduce available effects but may reject legitimate operations; a usable runner needs a narrow, testable contract.\n\nCoding and data agents transform model proposals into process execution, where OS-level limits become consequential.\n\n## Specifications and interfaces\n\nMechanism boundary\n\nWhat limits code after it starts running?\n\nPayload-only ledger; excludes allocator overhead, runtime memory and operating-system state. One MiB is 2^20 bytes. No real sandbox or memory measurement is executed here.\n\nEvidence type\n\nAuthored worked example\n\nWorked explanation with a bounded numeric or state example. This lesson does not claim an executing implementation of an external model or platform.\n\n### Interfaces\n\nDeclared input and state Input\n\nThe task defines the files, network endpoints and operations needed by the code runner.\n\nChecked outcome Output\n\nSeparate process containment, resource budgets and task correctness in a generated-code execution.\n\n## Check your understanding\n\n### A 40 MiB input and 32 MiB output overlap under a 64 MiB limit. Does the live payload fit?\n\n1.  Yes, because each allocation is below the limit\n2.  No, because at least 72 MiB is live\n3.  Yes, if the code says it is safe\n\nAnswer and reasoning\n\nNo, because at least 72 MiB is live\n\nThe live-set boundary includes both overlapping allocations, before metadata and other process memory.\n\n## Evidence and scope\n\nThis is a worked explanation, not an executing external platform, model or robot. The quantities and fixtures are authored. Source scope is recorded in the automation learning review manifest; no source benchmark or private system behavior is claimed. Payload-only ledger; excludes allocator overhead, runtime memory and operating-system state. One MiB is 2^20 bytes. No real sandbox or memory measurement is executed here.\n\nThe worked example explains this mechanism. General numerical labs are a reference; they do not execute this lesson’s full mechanism.\n\n## Sources\n\n-   [Linux man-pages · namespaces(7)](https://man7.org/linux/man-pages/man7/namespaces.7.html)\n-   [Linux man-pages · seccomp(2)](https://man7.org/linux/man-pages/man2/seccomp.2.html)\n\n[Published lesson data](https://semiaifoundry.com/ai-atlas/lesson-data/sandbox-egress-secrets-d95b556a68c180e2.json) · [Atlas releases and licensing](https://semiaifoundry.com/ai-atlas/licenses.html)\n\n## Continue exploring\n\n### Foundations\n\n-   [User authority and service identity](https://semiaifoundry.com/learn/atlas/tool-authority-identity/)\n\n### Related lessons\n\n-   [Tools, memory & agent loop](https://semiaifoundry.com/learn/atlas/tool-loop/)\n-   [Evaluation & the AGI frontier](https://semiaifoundry.com/learn/atlas/evaluation/)"
}