LinkedIn
X Developing Boomi Companion: Considering security for an AI agent skill
Creating AI agent skills containing detailed knowledge of how to interact with remote systems on a user's behalf is a new area of product development for most companies. Much of the tooling that exists in the software development world for ensuring code quality doesn't fully extend or apply to developing AI agent skills, which are primarily natural language text files.
The approachability of this format may entice users to ask an AI agent to naively create skills based on questionable/incomplete documentation, with very few guardrails to spot inefficient, insecure, or even blatantly incorrect instructions. The Boomi Companion team is attempting to elevate skill development by incorporating hard-won lessons from traditional software development, including not only being careful and considered in our approach to security, but also being transparent about the decisions we've made and how we've implemented our design choices. Enabling users and their agents with the equivalent of years of experience using the Boomi Enterprise Platform is extremely powerful, but convenience can (and usually does) come with security caveats and tradeoffs. This blog will demonstrate how the Boomi Companion development team has been considering those implications, the mitigations we've implemented, and what might still be desirable for "hardening" an agent-based build system.
Boomi Companion is provided under the BSD 2-Clause "Simplified" License. Anyone is free to download, use, and even modify these skills, but you are solely responsible for using Boomi Companion safely, and in accordance with any guidelines your organization provides.
With that out of the way, let's look at some of the situations we encountered and the mitigations we've put in place.
The Boomi Enterprise Platform API
The bc-integration plugin (the inaugural plugin for Boomi Companion) leverages the Boomi Platform API for platform interactions. That means we inherit the stability, security, and capabilities of this interface, which has been handling Boomi Enterprise Platform interactions for decades. AI agents using Boomi Companion can use this API to accomplish the same outcomes that human Boomi users create via the traditional web interface today.
The most novel security challenge we encountered during the development of Boomi Companion was protection against leaking sensitive data (such as credentials) into the context window, where it could be viewed, logged, and potentially used by the AI platform in ways we didn't intend. As this technology evolves, all users of AI agent skills should be vigilant in protecting their data and avoid exposing sensitive information to the context window of any AI session.
Boomi Enterprise Platform credential handling mitigation techniques
Boomi Companion authenticates to the Boomi Platform API using Basic authentication and a Platform API token. Check out Platform API Tokens overview and Platform API and Partner API authentication for further details. By default, an .env file located in the project folder (usually copied from the template workspace) is expected to contain the environment variables for many configurable aspects of Boomi Companion operation. This includes the BOOMI_USERNAME and BOOMI_API_TOKEN values, which should be considered sensitive. Although Boomi Companion provides basic protections as detailed below, we recommend taking additional steps to prevent unauthorized access to these plaintext files by local or remote users (file permissions, disk encryption, etc.), in addition to normal API key rotation policies.
Beyond basic protection of the .env file on disk, we've implemented some more AI-centric mitigations that reside in the template workspace.
- The included CLAUDE.md (agent instructions) and README.md (human instructions) explain that Platform credentials must not be handled directly by the agent, along with alternatives and justification.
- Custom curl commands are framed as "unexpected" behavior, which should be discussed with the user prior to execution.
- Explicit reasoning improves the likelihood of agent compliance with established rules.
- The included settings.json file in the plugin denies the Read and Bash tools from accessing .env files, providing a more "mechanical" protection against .env file reads.
- Rather than giving credentials directly to the agent, the agent can access Bash scripts that populate those credentials into short-lived, limited-scope environment variables for use in Platform API requests:
- These scripts source their common functions from a single, manageable location (boomi-common.sh).
- The tools use pure Bash scripting with minimal dependencies to ensure wide compatibility and a lower attack surface.
As these mitigations are all implemented through the template workspace, it is recommended that you occasionally update your template using the /configure-template-workspace command in addition to regularly reviewing your settings.json configuration.
These mitigations are dependent on mechanisms enabled through the Claude Code "plugin" format, which is the primary method of distribution for Boomi Companion skills. If you are leveraging these skills outside of the full plugin, you may wish to adapt our approach to your specific implementation scenario.
Connector credential handling mitigation techniques
When you use the Boomi Platform API to download a Connector component that contains credentials, the credentials are provided as encrypted strings rather than plaintext. This means the Boomi Companion skill can download, update, and reuse Connector components that exist in your account without the Agent storing, seeing, or exposing plaintext credentials at any point. We recommend configuring Connectors in the Boomi Enterprise Platform web UI to ensure these credentials are never exposed in the AI agent context window. Once Connectors are configured in your account, you can choose to add them to the "preferred_connections.md" file in your project workspace (or even the template workspace) to point Boomi Companion to the components you mean when you say "the development database" or "the production mailserver". Use of preferred_connections.md is provided as a convenience, but you may always provide Boomi Companion a component URL directly during a session without reducing security. This approach (configure connections in web UI, retrieve by component URL) promotes Connector reuse, which has been a long-standing Boomi best practice.
The preferred_connections.md file contains human-friendly names and component URLs, not live component XML or credentials.
Logging and Telemetry
By default, using Boomi Companion does not create any additional logging or telemetry. AI agent harnesses and the Boomi Enterprise Platform API will of course create logs, but that is outside Boomi Companion's control. Opt-in, local-only debug logging for Boomi Companion is available by setting BOOMI_COMPANION_LOG_ACTIVITY=1 in your workspace (or template workspace) .env file. These logs may contain sensitive data, but are never collected by Boomi - they are provided for your local troubleshooting/analysis only. The skill contains specific instructions and reference information about these files, discouraging any request to share them.
Boomi Companion activity logs (when enabled) are stored in the .activity-log folder inside the project folder.
A final word
We've tried to give reasonable, secure defaults to protect the most sensitive operations of this skill, but it's important to recognize that there is no practical way to ensure a user doesn't intentionally inject credentials or other sensitive information into the AI agent context window. This may be done for legitimate reasons (building a short-lived demo with simulated data), and Boomi Companion enables you to work however you need to - including giving you the power to override the defaults/instructions we've provided. This also includes the ability to harden this skill in ways that are impractical for us (the Boomi Companion development team) to implement globally. You may want to modify this skill to integrate with a secrets manager, rather than using local .env files, or to implement managed session logging. These approaches and others will vary entirely on your risk profile and use case, and we encourage you to take this skill and adapt it to your needs. Let us know how you are approaching these challenges - we'd love to hear any feedback you have at developer-offerings@boomi.com.
Acknowledgments
Boomi Companion v1 is the work of Chris Cappetta, Ben DeBoer, and Shasta Hayes. Thanks to everyone who tested the early versions of Boomi Companion and those who continue to provide feedback! Special thanks to the Boomi Enterprise Platform API team, as Boomi Companion wouldn't be what it is today without them.
