<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									FedRAMP and Government Deployments - openclawsecurity.net Forum				            </title>
            <link>https://openclawsecurity.net/community/fedramp-and-government/</link>
            <description>openclawsecurity.net Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Tue, 30 Jun 2026 12:16:31 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>What&#039;s the best way to scope the boundary if the agent uses external APIs?</title>
                        <link>https://openclawsecurity.net/community/fedramp-and-government/whats-the-best-way-to-scope-the-boundary-if-the-agent-uses-external-apis/</link>
                        <pubDate>Mon, 29 Jun 2026 06:59:58 +0000</pubDate>
                        <description><![CDATA[If your agent calls out to external APIs, that&#039;s your boundary. The API endpoints are in. Full stop.

Stop trying to carve out exceptions. The entire data flow is part of your authorization ...]]></description>
                        <content:encoded><![CDATA[If your agent calls out to external APIs, that's your boundary. The API endpoints are in. Full stop.

Stop trying to carve out exceptions. The entire data flow is part of your authorization scope. This means:
* The external service's FedRAMP status (or lack of it) directly impacts your ATO.
* Every connection, credential, and data packet in transit is in scope.
* Your logging and monitoring must cover the entire chain, not just your container.

Treat it as a single system. If the external API isn't FedRAMP authorized, your entire system isn't either. Architect for that reality.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/fedramp-and-government/">FedRAMP and Government Deployments</category>                        <dc:creator>Frank O&#039;Brien</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/fedramp-and-government/whats-the-best-way-to-scope-the-boundary-if-the-agent-uses-external-apis/</guid>
                    </item>
				                    <item>
                        <title>Showcase: Our approval package artifact for a simple query agent.</title>
                        <link>https://openclawsecurity.net/community/fedramp-and-government/showcase-our-approval-package-artifact-for-a-simple-query-agent/</link>
                        <pubDate>Mon, 29 Jun 2026 01:01:11 +0000</pubDate>
                        <description><![CDATA[Another vendor just posted a &quot;FedRAMP Ready&quot; slide. Meaningless. Ready isn&#039;t authorized.

We actually got a simple query agent through a FedRAMP Moderate JAB P-ATO. Here&#039;s the core of our ap...]]></description>
                        <content:encoded><![CDATA[Another vendor just posted a "FedRAMP Ready" slide. Meaningless. Ready isn't authorized.

We actually got a simple query agent through a FedRAMP Moderate JAB P-ATO. Here's the core of our approval package artifact for boundary scoping. This is what proof looks like.

Key inclusions from our Continuous Monitoring package:
*   **Component Inventory &amp; Data Flow Mapping:** Explicitly listing every container, API, and log stream. Showed where prompt/query data resides in-memory vs. at-rest.
*   **Third-Party Dependency Attestations:** For the underlying LLM service (IL5 compliant instance) and vector DB. Had their SSPs and latest audit reports.
*   **Boundary Diagram:** Highlighted the agent runtime as a FedRAMP-authorized component, with clear demarcation to the customer's non-authorized internal data sources.
*   **Threat Model Excerpt:** Focused on data exfiltration via agent prompt injection and sanitization controls. Documented the manual review workflow for high-risk queries.
*   **POA&amp;M Items We Accepted:** Two moderate findings related to log retention granularity. Showed the mitigation timeline.

The package was 90% about proving the operational and management controls, not the agent's code. The assessors cared most about change management, contingency planning, and personnel screening for the system hosting the agent.

Ask if you want specifics on how we handled the inherited controls from our IaaS provider.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/fedramp-and-government/">FedRAMP and Government Deployments</category>                        <dc:creator>Linda H.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/fedramp-and-government/showcase-our-approval-package-artifact-for-a-simple-query-agent/</guid>
                    </item>
				                    <item>
                        <title>Did you see the GSA&#039;s pilot project using agents for form processing? Skeptical.</title>
                        <link>https://openclawsecurity.net/community/fedramp-and-government/did-you-see-the-gsas-pilot-project-using-agents-for-form-processing-skeptical/</link>
                        <pubDate>Sun, 28 Jun 2026 10:01:24 +0000</pubDate>
                        <description><![CDATA[The General Services Administration&#039;s recent announcement regarding a pilot project utilizing &quot;intelligent agents&quot; for automated form processing raises immediate concerns from a cryptographi...]]></description>
                        <content:encoded><![CDATA[The General Services Administration's recent announcement regarding a pilot project utilizing "intelligent agents" for automated form processing raises immediate concerns from a cryptographic control perspective. While the efficiency gains for citizens are a stated goal, the technical details released are insufficient to evaluate compliance with the core security families of NIST SP 800-53, particularly SC-28 (Protection of Information at Rest) and SC-8 (Transmission Confidentiality and Integrity).

My primary skepticism centers on the agent's state management. In a FedRAMP Moderate or IL4/IL5 context, the agent runtime will necessarily handle, cache, or process PII and potentially other sensitive data. The critical questions left unanswered are:

*   **Key Lifecycle for Agent State:** Is the agent's working state (e.g., in-memory data, cached form fields) encrypted? If so, where are the encryption keys derived or stored? A hardware security module (HSM) or secure enclave (e.g., Intel SGX, AMD SEV) is non-negotiable for key generation and protection at this impact level.
*   **State Encryption at Rest:** When the agent's state is serialized to disk—for persistence, checkpointing, or crash recovery—what encryption schema is used? A simple AES-CBC implementation without proper integrity checking (e.g., AES-GCM) is inadequate.
*   **Secret Rotation:** Form processing may involve credentials to access backend systems. How are these embedded secrets or tokens rotated without redeploying the entire agent? A static, baked-in credential would be a significant finding.

Consider a naive implementation, which would be a compliance failure:
```python
# Hypothetical problematic state serialization
import pickle
import json

agent_state = {'form_data': 'Sensitive PII', 'auth_token': 'static_token'}
with open('state.pkl', 'wb') as f:
    f.write(pickle.dumps(agent_state))  # No encryption, integrity check
```

The acceptable pattern requires envelope encryption with a key management service (KMS) backed by an HSM:
```python
# Conceptual pattern for IL4+ compliance
encrypted_data_key = kms.generate_data_key(key_id='hsm-backed-key')
ciphertext, tag = aes_gcm_encrypt(
    plaintext=serialize_state(agent_state),
    key=encrypted_data_key
)
# Store only ciphertext, tag, and the encrypted data key
persist_to_disk(ciphertext, tag, encrypted_data_key)
```

Has anyone involved in the pilot's technical review seen a publicly available System Security Plan (SSP) addendum or a CONOPS document that addresses these specific control implementations? Without clarity on these points, the pilot risks normalizing an architecture that cannot pass a rigorous security assessment.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/fedramp-and-government/">FedRAMP and Government Deployments</category>                        <dc:creator>Yuki Sato</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/fedramp-and-government/did-you-see-the-gsas-pilot-project-using-agents-for-form-processing-skeptical/</guid>
                    </item>
				                    <item>
                        <title>Practical walkthrough: Installing Claw on a hardened, approved STIG image</title>
                        <link>https://openclawsecurity.net/community/fedramp-and-government/practical-walkthrough-installing-claw-on-a-hardened-approved-stig-image/</link>
                        <pubDate>Sat, 27 Jun 2026 12:01:05 +0000</pubDate>
                        <description><![CDATA[Alright team, I&#039;ve seen a few questions pop up about getting agent runtimes deployed onto properly hardened government systems. It&#039;s one thing to run a demo on a vanilla box, and another to ...]]></description>
                        <content:encoded><![CDATA[Alright team, I've seen a few questions pop up about getting agent runtimes deployed onto properly hardened government systems. It's one thing to run a demo on a vanilla box, and another to get it integrated into an existing, approved stack that's already locked down per DISA STIGs. I just went through this process on a FedRAMP Moderate (IL4) boundary, so here's a practical walkthrough of the key hurdles and solutions.

The core challenge is that STIG'd images often have layers of restrictions that conflict with default installation methods. Here's what I had to account for:

*   **Network egress controls:** The system had no direct internet access. This meant all dependencies had to be sourced internally.
*   **User privilege limitations:** Standard service account with minimal privileges; no `sudo` for package management.
*   **Pre-existing security tooling:** Host-based firewalls (iptables/nftables, Windows Firewall with advanced rules) and HIDS were already configured with strict allow-lists.
*   **Non-standard ports:** The approved list for outbound connections was extremely narrow.

My process looked something like this:

**1. Pre-Stage All Dependencies.** I worked with our repo team to get every single package, library, and the Claw runtime binaries themselves into the agency's approved internal repository. This included pulling in specific versions of Python interpreters and libraries that were already on the approved software list.

**2. Service Account Configuration.** Instead of using a generic "claw" user, I mapped the agent's service to an existing, STIG-compliant service account already provisioned for middleware applications. Its home directory and necessary paths (`/opt/claw`) had permissions set in advance via a Puppet manifest, following the principle of least privilege.

**3. Firewall and HIDS Integration.** This was the most manual step. I had to submit a change request to add the agent's internal loopback and designated high-port communication paths to the host firewall allow-list. For the HIDS, I provided the executable paths and expected behavior patterns to the security team to be added to their baseline to prevent false positives.

The main takeaway? Success here is less about the install command and more about the prep work within your change and configuration management processes. You need clear documentation on:
- Network flow diagrams for the agent components
- A full software bill of materials (SBOM) for compliance
- Exactly which directories need what permissions

Getting it running on the hardened image was straightforward once the groundwork with the infosec and platform teams was laid. The key is integrating the deployment into *their* existing playbooks, not the other way around.

Anyone else tackled a similar deployment? Curious how you handled the artifact signing and integrity verification in an air-gapped scenario.

YMMV.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/fedramp-and-government/">FedRAMP and Government Deployments</category>                        <dc:creator>Laura Chen</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/fedramp-and-government/practical-walkthrough-installing-claw-on-a-hardened-approved-stig-image/</guid>
                    </item>
				                    <item>
                        <title>Beginner question: What exactly is an &#039;agent runtime&#039; from a FedRAMP scoping perspective?</title>
                        <link>https://openclawsecurity.net/community/fedramp-and-government/beginner-question-what-exactly-is-an-agent-runtime-from-a-fedramp-scoping-perspective/</link>
                        <pubDate>Thu, 25 Jun 2026 20:00:23 +0000</pubDate>
                        <description><![CDATA[The term &quot;agent runtime&quot; appears frequently in FedRAMP System Security Plans (SSPs) and deployment guides, but its scoping is often ambiguous. From a logging and monitoring perspective, I fi...]]></description>
                        <content:encoded><![CDATA[The term "agent runtime" appears frequently in FedRAMP System Security Plans (SSPs) and deployment guides, but its scoping is often ambiguous. From a logging and monitoring perspective, I find this problematic. Ambiguity in scoping leads to gaps in audit coverage and telemetry collection.

From a FedRAMP scoping perspective, the "agent runtime" is not merely the agent binary. It is the *execution context* required for the agent to function as intended. This includes, at a minimum:
* The agent process itself and its child processes.
* The host-level dependencies (libraries, system calls) it utilizes.
* The local storage it uses for caching, buffering, or state (e.g., `/var/lib/agent`).
* The network listeners and outbound connections it initiates.
* The configuration files and secrets it accesses.

Crucially, if the agent has the ability to execute scripts, plugins, or dynamic modules, those execution engines (e.g., a Python interpreter, a WASM runtime) are also part of the runtime boundary. This is a common scoping oversight.

Consider a monitoring agent that uses a local SQLite database for metrics aggregation before forwarding. A naive scope might only include the agent binary and its config. The correct scope must also include:
- The SQLite library and files.
- The temporary disk space used for WAL journals.
- The procedural language (e.g., for custom queries) if supported.

```yaml
# Example scoping description for an SSP
Component: Security_Log_Forwarder_Agent_Runtime
Description: Includes the fluent-bit process, its loaded Golang/ Lua plugin modules, the on-disk buffer at /var/log/agent/buffer, and all associated file descriptors for reading host logs and forwarding to the authorized log collector.
Boundary: The runtime is contained within the provisioned VM. Communication outside the boundary is solely to the authorized log collector endpoint over TLS.
```

Failure to properly define this scope can lead to compliance findings. If an agent's runtime can execute arbitrary code but that capability is not assessed, it creates an uncontrolled code execution vector within the authorization boundary. My primary interest is ensuring all runtime behavior is captured in logs and metrics (e.g., via Prometheus node_exporter, auditd rules) for anomaly detection. An undefined runtime component is an unmonitored one.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/fedramp-and-government/">FedRAMP and Government Deployments</category>                        <dc:creator>Nina G.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/fedramp-and-government/beginner-question-what-exactly-is-an-agent-runtime-from-a-fedramp-scoping-perspective/</guid>
                    </item>
				                    <item>
                        <title>Guide: Integrating Claw agent logs with our SIEM for continuous monitoring.</title>
                        <link>https://openclawsecurity.net/community/fedramp-and-government/guide-integrating-claw-agent-logs-with-our-siem-for-continuous-monitoring/</link>
                        <pubDate>Thu, 25 Jun 2026 13:19:29 +0000</pubDate>
                        <description><![CDATA[Hi everyone. I&#039;m setting up a local Claw deployment in my home lab and need to get the agent logs into my SIEM (Wazuh) for monitoring. I&#039;ve been reading about the Nano Claw and Iron Claw mod...]]></description>
                        <content:encoded><![CDATA[Hi everyone. I'm setting up a local Claw deployment in my home lab and need to get the agent logs into my SIEM (Wazuh) for monitoring. I've been reading about the Nano Claw and Iron Claw models, and I want to make sure I'm capturing the right events, especially for local AI workloads.

Could someone share a practical example of the log sources and fields I should be forwarding? I'm particularly interested in the audit trails for model access and agent actions. My current setup uses syslog forwarding, but I'm not sure if I'm missing structured data from the agent's own journal.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/fedramp-and-government/">FedRAMP and Government Deployments</category>                        <dc:creator>Jamie Rivera</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/fedramp-and-government/guide-integrating-claw-agent-logs-with-our-siem-for-continuous-monitoring/</guid>
                    </item>
				                    <item>
                        <title>ELI5: Why can&#039;t we just use the commercial cloud version with a BAA?</title>
                        <link>https://openclawsecurity.net/community/fedramp-and-government/eli5-why-cant-we-just-use-the-commercial-cloud-version-with-a-baa/</link>
                        <pubDate>Thu, 25 Jun 2026 03:01:23 +0000</pubDate>
                        <description><![CDATA[I keep seeing this question pop up, not just here but in other circles. It seems logical, right? If a SaaS vendor signs a Business Associate Agreement (BAA) for HIPAA, that&#039;s good enough for...]]></description>
                        <content:encoded><![CDATA[I keep seeing this question pop up, not just here but in other circles. It seems logical, right? If a SaaS vendor signs a Business Associate Agreement (BAA) for HIPAA, that's good enough for healthcare data. So why isn't the equivalent good enough for government data at the IL4/IL5 level?

From my homelab tinkering, I've learned that a BAA is primarily about legal liability and promises. It says, "Yes, we are contractually obligated to protect this data." But FedRAMP is about *proving* you have specific, audited controls in place, on a *specific* set of systems. It's not just a promise; it's a continuous evidence trail.

Think of it like this: In my lab, I can promise my family I won't let their devices get malware (my "BAA"). But to prove it, I'd need to show them my Pi-hole logs, my firewall rules, my isolated VLANs, and have a third-party audit that configuration. That's closer to FedRAMP.

The core issue with using the commercial cloud version is **shared tenancy and boundary scoping**. For a FedRAMP Moderate (IL4) authorization, the entire operational environment—every piece of hardware, hypervisor, network path, and supporting service that touches the data—needs to be assessed and authorized. The commercial multi-tenant cloud service is a huge, constantly changing boundary. You can't isolate *your* data's path from every other customer's at the infrastructure level.

In an air-gapped deployment, the problem is even more obvious. You can't have agents phoning home to a commercial, internet-facing management plane. The "agent runtime" needs to live entirely within the government's own accredited boundary, which means a dedicated, isolated instance of the management platform.

So, the BAA is the starting line, but FedRAMP is the entire obstacle course with judges watching every step. You can't just take the commercial track; you need a separate, government-only one.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/fedramp-and-government/">FedRAMP and Government Deployments</category>                        <dc:creator>Raj Patel</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/fedramp-and-government/eli5-why-cant-we-just-use-the-commercial-cloud-version-with-a-baa/</guid>
                    </item>
				                    <item>
                        <title>Has anyone performed a FIPS 140-2 validation for the crypto used in an agent framework?</title>
                        <link>https://openclawsecurity.net/community/fedramp-and-government/has-anyone-performed-a-fips-140-2-validation-for-the-crypto-used-in-an-agent-framework/</link>
                        <pubDate>Wed, 24 Jun 2026 19:00:21 +0000</pubDate>
                        <description><![CDATA[Hi folks. I&#039;m deep into a project that requires deploying some of our agent logic into an environment with a strict FIPS 140-2 requirement. We&#039;re typically a Homebrew-on-Apple-Silicon, run-i...]]></description>
                        <content:encoded><![CDATA[Hi folks. I'm deep into a project that requires deploying some of our agent logic into an environment with a strict FIPS 140-2 requirement. We're typically a Homebrew-on-Apple-Silicon, run-it-locally kind of shop, but this one's for a partner with federal adjacent needs.

I'm trying to cut through the marketing. Most framework docs just say "we use TLS" or "crypto is secure." I need specifics. Has anyone here actually gone through, or even seriously assessed, the steps to validate the cryptographic module within an agent runtime (think LangChain, AutoGen, or even bespoke setups using Python/Go) against FIPS 140-2?

My immediate pain points:
*   **Libraries:** If you're using Python, are you locking to a specific OpenSSL version? Using `cryptography` module built against a FIPS-validated OpenSSL? Or using a platform-specific library like CommonCrypto on macOS (which is validated)?
*   **Dependencies:** The nightmare of dependency trees. That one transitive dependency that links against a non-compliant libcrypto will break the entire validation boundary.
*   **Boundary Scoping:** Is the entire application, including the agent runtime and inference engine, within the validated boundary? Or can we isolate just the crypto operations (like TLS for API calls, signing) into a compliant module?

For example, a naive setup using `requests` and common Python libs is almost certainly non-compliant:

```python
# This common pattern is a FIPS nightmare
import hashlib
from cryptography.fernet import Fernet
```

I'm looking for real war stories and workarounds. Did you have to compile everything from source against a validated OpenSSL? Switch languages? Use a FIPS-enabled OS and then jump through hoops to ensure your runtime environment used the system libraries?

Any insight, especially around keeping things efficient and manageable (ironclad, but not a resource hog), would be hugely appreciated. The air-gapped deployment guide I'm drafting will be shared here when it's done.

~Fiona]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/fedramp-and-government/">FedRAMP and Government Deployments</category>                        <dc:creator>Fiona T.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/fedramp-and-government/has-anyone-performed-a-fips-140-2-validation-for-the-crypto-used-in-an-agent-framework/</guid>
                    </item>
				                    <item>
                        <title>Help: Agent callback logs are picking up PII from our internal ticketing system.</title>
                        <link>https://openclawsecurity.net/community/fedramp-and-government/help-agent-callback-logs-are-picking-up-pii-from-our-internal-ticketing-system/</link>
                        <pubDate>Wed, 24 Jun 2026 17:38:34 +0000</pubDate>
                        <description><![CDATA[Hey everyone. Ran into a concerning issue during some internal red teaming of our agent framework and wanted to see if anyone else has dealt with this.

We&#039;re using a fairly standard agent s...]]></description>
                        <content:encoded><![CDATA[Hey everyone. Ran into a concerning issue during some internal red teaming of our agent framework and wanted to see if anyone else has dealt with this.

We're using a fairly standard agent setup with a tool that can query our internal ticketing system (ServiceNow) to fetch and summarize open issues. During testing, the agent works great. However, we've discovered that the callback handler we're using to log all agent tool executions (for audit/debugging) is capturing the *full raw response* from the ticketing API before it gets sent to the LLM for summarization. This means our log files are now full of unredacted PII—names, email addresses, sometimes even phone numbers from the ticket descriptions.

Here's a simplified version of the logging callback we were using:

```python
class ToolLoggingCallback(BaseCallbackHandler):
    def on_tool_end(self, output, **kwargs):
        with open("agent_tool_logs.jsonl", "a") as f:
            log_entry = {
                "tool": kwargs.get("tool_name"),
                "output_snapshot": output  # This is the problem!
            }
            f.write(json.dumps(log_entry) + "n")
```

The core issue is that `output` here is the entire API response. We're scoping our system for a potential FedRAMP Moderate (IL4) environment, so this is a major compliance red flag. Logs are considered part of the authorization boundary, and we can't have PII sitting in plain text in them.

Has anyone implemented a pattern for sanitizing these kinds of tool outputs *before* they hit logging callbacks? I'm looking at options like:
- Wrapping the tool itself to strip PII before returning.
- Creating a custom callback that processes the output through a local NER model or regex filters before writing.
- Maybe even using something like NeMo Guardrails as an inline filter on the data flow.

The tricky part is we still need the *agent* to see the raw data to perform its task, but the *logs* must be clean. Any design patterns or prior art in this space would be hugely appreciated.

--leo]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/fedramp-and-government/">FedRAMP and Government Deployments</category>                        <dc:creator>Leo F.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/fedramp-and-government/help-agent-callback-logs-are-picking-up-pii-from-our-internal-ticketing-system/</guid>
                    </item>
				                    <item>
                        <title>Help: Audit wants evidence that the agent can&#039;t escalate its own privileges.</title>
                        <link>https://openclawsecurity.net/community/fedramp-and-government/help-audit-wants-evidence-that-the-agent-cant-escalate-its-own-privileges/</link>
                        <pubDate>Wed, 24 Jun 2026 14:38:54 +0000</pubDate>
                        <description><![CDATA[Audit&#039;s got a good point. In an orchestration framework, especially in a government context, an agent that can self-elevate breaks the entire security model. It turns a contained workload in...]]></description>
                        <content:encoded><![CDATA[Audit's got a good point. In an orchestration framework, especially in a government context, an agent that can self-elevate breaks the entire security model. It turns a contained workload into a potential pivot point.

From our work on IronClaw, we treat this as a three-layer problem: the runtime isolation boundary, the agent's intrinsic capabilities, and the orchestration control plane.

First, the isolation boundary. You need to provide evidence that the agent's code execution is physically constrained. If you're using gVisor or a microVM (like Firecracker), your audit trail is the configuration that drops all unnecessary capabilities and the launch parameters. For a Wasm-based runtime (like with Wasmtime), it's the demonstration that the Wasm module has no host calls (`wasmtime --disable-logging --disable-cache --wasm-features -all`). A concrete config snippet helps:

```toml

type = "wasmtime"
strict_security = true
disallowed_imports = 
max_memory = 128  # MiB
```

Second, the agent's own code. You must show it has no path to execute arbitrary system calls or spawn subprocesses. This is where a capability-based runtime shines. Provide the auditors with the SDK's API surface documentation—it should be conspicuously absent of any `exec`, `shell`, or filesystem write calls outside a tightly scoped scratch area.

Finally, the control plane. This is often missed. Evidence must show that the orchestration layer cannot be commanded by the agent to escalate privileges. The agent's API back to the controller should be a strict subset of non-modifying queries (status, metrics) and a clearly defined, pre-authorized action set. Any "upgrade" or "reconfigure" command must originate from a separate, authenticated control channel the agent cannot write to.

Can you share which runtime isolation layer you're using? The evidence path differs between a hardened container, a microVM, and a Wasm sandbox.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/fedramp-and-government/">FedRAMP and Government Deployments</category>                        <dc:creator>wasm_isolator</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/fedramp-and-government/help-audit-wants-evidence-that-the-agent-cant-escalate-its-own-privileges/</guid>
                    </item>
							        </channel>
        </rss>
		