How We Built a Multi-Agent System using OpenClaw and Deployed It Safely on AWS
Why we built a code-to-doc pipeline on OpenClaw
Recently, Christoph Bartenstein and I were discussing harnessing agentic capabilities of platforms like OpenClaw. As a native AI company at Trent AI, we live and breathe AI and are always looking for opportunities to deploy it in our internal systems. The reason for this is two fold: we want to learn how agentic systems are evolving, and at the same time make our work deliver more with less. These two reasons are important in our early journey of securing agents.
An interesting and practical use case that meets both criteria is our public documentation. The engineering team is shipping features at unprecedented speed. Documentation has always been a catching-up process aka documentation drift. The code keeps changing, the docs fall out of date, and keeping docs in sync with code 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.
The idea was exciting and we decided to build it on OpenClaw. The choice of building on OpenClaw is deliberate because the platform is hugely popular and the architecture is open; data flows can be visualized and inspected.
How we built the multi-agent system on OpenClaw, and handled context handoff
As usual, we started to break down the use case into small components. This gave us flexibility to improve specific areas without regression, and an opportunity to build multi agent system. We ended up with following components:
- Change Scanner: This component reads code repositories, fetches merged pull requests, and impacted files intelligently filtering any noise and sensitive files.
- Doc Classifier: This components is heart of the system. It triages all the changes into areas like breaking changes, new features or deprecated changes or internal only. It assigns confidence score to these areas which makes debugging and improvement easier.
- Doc Publisher: This component converts raw files into customer facing documents based on style and tone specific to the project. It also reconciles existing documents and create a pull request with final updated documentation.
- Orchestrator: This component works as coordinator between other components, tracks any failures and try to recover if things go wrong. This also run whole pipeline on schedule making whole process automated.
- GitHub Tools: These are just scripts to connect to GitHub used by Change Scanner & Doc Publisher components.
For deploying these components, we decided to build agents for each component. The idea was to build an understanding of a multi-agent system. In OpenClaw, an agent is a simple standalone entity which has personality and operating instructions. Basically a bunch of skill md files in isolated workspace directory. This allows an agent to work independently with its own memory and tools.
For our use case, all the components need clear invocation and handoff capability for sharing context. Unfortunately the OpenClaw platform is not mature for multi agent work; it has the capability to invoke other agents via session management tools but does not have clear hand-off with context. For context hand-off we opted to use shared files; a common practice now for context sharing in long-running agents, to overcome this limitation.
Here is what the high level flow looks like:
Orchestrator manages whole pipeline where each agent is responsible to do one thing following single responsibility principle. Context handoff is done via shared files.
How we deployed the agents safely on AWS
Once the agent architecture was finalized, we needed to host it. We chose AWS because of our experience with the platform. Deploying the system safely is critical for us, since it has access to our intellectual property in private repositories.
The threats we modeled before deploying, and how we mitigated each with Trent
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. See the following example of Trent Security Advisor helping harden security in action:
Trent’s Security Advisor began by explicitly enumerating threats: data exfiltration, code pollution, supply-chain tampering, lateral movement, and secret leakage. It then reviewed 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 access 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, which we treat 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 continue to evolve, deploying them safely will depend on native security controls from the underlying framework and infrastructure, where they are deployed. It is really important for organizations to have visibility into data flow and threat boundaries; so risk posture can be assessed.
The code-to-doc agents are available in the public repo, and you can see an example pull request created by the system here. If you’d like your public documents updated or have similar requirement, feel free to copy it and deploy.
Let me know if you have any questions or want to discuss agentic system safety.
