By Brajesh Kumar, Trent (Agentic AI Security)
Why we built a code-to-doc pipeline on OpenClaw
Recently, Christoph Bartenstein and I were discussing how to harness the agentic capabilities of platforms like OpenClaw. As an AI-native company, we at Trent AI are always looking for opportunities to deploy AI in our internal systems. The reason is twofold: we want to learn how agentic systems are evolving, and at the same time make our work deliver more with less.
A practical use case that meets both criteria is our public documentation. The engineering team is shipping features at unprecedented speed, and documentation has always been a catching-up process, aka documentation drift. The code keeps changing, the docs fall out of date, and syncing them turns into constant manual work. We wanted to change that by automatically generating public documentation from code, or at the very least producing draft material for humans to review before publishing.
We decided to build it on OpenClaw. The choice is deliberate: the platform is hugely popular and the architecture is open, so data flows can be visualized and inspected.
How we built the multi-agent system and handled context handoff
We started by breaking the use case down into small components. This let us improve specific areas without regression. We ended up with these components:
- Change Scanner: Reads code repositories, fetches merged pull requests and impacted files, and filters out noise and sensitive files.
- Doc Classifier: The heart of the system. It triages all changes into areas like breaking changes, new features, deprecations, or internal only, and assigns a confidence score to each, which makes debugging and improvement easier.
- Doc Publisher: Converts raw files into customer-facing documents in the project's style and tone, reconciles existing documents, and creates a pull request with the updated documentation.
- Orchestrator: Coordinates the other components, tracks failures, and tries to recover when things go wrong. It also runs the pipeline on a schedule.
- GitHub Tools: Scripts to connect to GitHub, used by the Change Scanner and Doc Publisher.
We built an agent for each component, to develop an understanding of multi-agent systems. In OpenClaw, an agent is a simple standalone entity with a personality and operating instructions: basically a bunch of skill md files in an isolated workspace directory. This lets an agent work independently with its own memory and tools.
For our use case, every component needs clear invocation and handoff for sharing context. Unfortunately, OpenClaw is not yet mature for multi-agent work. It can invoke other agents via session management tools, but has no clear handoff with context. To overcome this limitation we used shared files for context handoff, a common practice now in long-running agents.
How we deployed the agents safely on AWS
We chose AWS to host it because of our experience with the platform. Deploying safely was critical, since the system has access to our intellectual property in private repositories.
The threats we modeled before deploying
The two principles guiding any agentic deployment are least privilege and a tight blast radius. The system gets only the access it needs, and any compromise stays contained. We used Trent's Claude Code Security to build security into this project from the design phase.
The review began by explicitly enumerating threats: data exfiltration, code pollution, supply-chain tampering, lateral movement, and secret leakage. It then went through each agent and network path to map risks to mitigations. Artifacts from that review (architecture diagram, allow-list rationale, debugging gotchas) are committed alongside the code, so future contributors inherit them instead of rediscovering them.
Locking down AWS: no public IP, SSM-only access, egress allow-list
The agents run on a single EC2 instance inside a VPC with no public IP and no inbound rules. The only access path is AWS Systems Manager Session Manager: no SSH keys to manage and no ports to expose. Operators reach the OpenClaw UI by SSM port-forwarding to localhost; the gateway binds only to the loopback interface.
For egress, we use AWS Network Firewall with a stateful FQDN allow-list. The instance can only talk to required services like GitHub, the Bedrock control plane, and a small set of package mirrors. Everything else is blocked. The deployment is done via an AWS CloudFormation template that is version controlled and reviewed.
What GitHub App permissions the agents get, and what we denied
The agents authenticate via a dedicated GitHub App installed only on the relevant repository, not via personal tokens. Permissions are scoped to pull_requests:read+write and contents:read+write. There is no admin access, no actions permission, and no metadata writes. On the GitHub side, branch protection requires a human reviewer on every PR the agents open. The agents can read and propose, but never merge their own work.
Containing the blast radius of prompt injection with agentToAgent
Inter-agent calls are gated by OpenClaw's agentToAgent setting: a boolean plus an allow-list of agent IDs. Today there is no fine-grained control over which agents may talk to which, and we treat that as a known limitation. We deploy this stack with only the four code-to-doc agents, no shared workspace, no extra tools, and no other secrets. If prompt injection compromises one of them, the blast radius is limited to the documentation pipeline.
What it takes to deploy multi-agent systems safely
As agentic systems evolve, deploying them safely will depend on native security controls from the underlying framework and the infrastructure they run on. Organizations need visibility into data flow and threat boundaries so risk posture can be assessed.
The code-to-doc agents are in the public repo, and you can see an example pull request created by the system. If you want your public docs kept in sync with code, feel free to copy it and deploy.
Top comments (0)