DEV Community

RagLeap
RagLeap

Posted on

Making Remote Tool Integrations Safer: Inside RagLeap Integrations v0.5.0

A technical walkthrough of controlled UTCP query parameters, narrow authentication handling, and post-release verification

A closer look at owner-controlled UTCP configuration, authentication handling, and 626 tests.

Remote tool integration is one of the most useful capabilities in an AI agent platform. It is also an area where security decisions matter.

An AI employee should not automatically trust every remote tool definition it discovers. Tool URLs, authentication declarations, query parameters, and input schemas need explicit boundaries.

With RagLeap Integrations v0.5.0, we have taken another step toward making remote tool connections more controlled and predictable.

Released on November 11, 2026, this version introduces two owner-controlled additions to the UTCP client and fixes a URL-handling issue.

GitHub Release: https://github.com/ragleap/ragleap-core/releases/tag/ragleap-integrations-v0.5.0

PyPI: https://pypi.org/project/ragleap-integrations/0.5.0/

1. Owner-controlled query parameters

The new allowed_query configuration lets the owner explicitly define which static query parameter names are permitted in a tool URL.

For example, an owner can allow specific parameter names rather than accepting arbitrary query parameters from a remote tool definition.

The implementation enforces several restrictions:

  • A maximum of 8 allowed parameter names.
  • Parameter names must follow a restricted character set.
  • Duplicate names are rejected.
  • Placeholder values are not accepted.
  • Query parameters that conflict with tool input properties are rejected.
  • Runtime arguments cannot override static query parameters.

Static query parameters are sent first, followed by the tool arguments. If a runtime argument attempts to reuse a static parameter name, the call is refused and no request is sent.

The default configuration remains empty, preserving the previous v0.4.0 behavior.

The objective is straightforward: the owner decides which static URL parameters a remote tool may use.

2. A deliberately narrow authentication format

Authentication handling is another important part of remote tool integration.

Version 0.5.0 accepts one specific authentication declaration:

  • auth_type: api_key
  • location: header
  • var_name: Authorization
  • api_key: Bearer ${NAME}

No additional keys are accepted in this format.

This is intentionally narrow. It describes the existing client behavior of sending an owner-provided token as an Authorization Bearer header to an approved origin.

Importantly, the ${NAME} placeholder is not resolved from environment variables or any other source.

If the owner has not supplied a token, the tool is skipped with a useful configuration hint. Other authentication formats and auth_tools remain unsupported, consistent with the previous behavior.

This is not an attempt to implement every authentication mechanism. It is a controlled acceptance of one known format.

3. Fixing malformed tool URLs

Version 0.4.0 accepted a tool URL ending in a bare question mark.

That could result in a request being sent with two question marks.

Version 0.5.0 now rejects such URLs when the URL has a query string or fragment in that malformed form.

Small URL-handling issues matter because remote integrations should fail safely rather than silently constructing unexpected requests.

4. Testing beyond ordinary unit tests

We wanted to verify more than whether the new code passed its basic tests.

The release includes:

  • 626 total tests.
  • 622 passed and 4 skipped without the optional security extra.
  • 626 passed with the security extra.
  • 81 new tests compared with v0.4.0.
  • 48 of 52 deliberate mutations were caught; the remaining 4 were equivalent mutations.
  • A test gap discovered during the first mutation round was corrected.

Testing was performed using Python 3.10.12 in clean virtual environments.

We also performed post-release checks:

  • PyPI wheel and source distribution SHA-256 hashes matched their TestPyPI counterparts.
  • A normal pip installation fetched the expected wheel.
  • Installed files matched the source.
  • pip check completed cleanly, with and without the optional extra.
  • Smoke tests passed.
  • Source distribution tests passed against the installed wheel.

These checks help establish that the published package is consistent with the tested release source.

5. What we have not verified

We believe technical transparency is just as important as announcing new features.

There are still things this release does not claim to have verified:

  • A real tool call against a live UTCP server.
  • The normative UTCP specification text.
  • Whether a vendor returns the same manual when a Bearer token is sent.

We inspected a publicly accessible UTCP manual and observed its tool definitions and authentication shapes. This was discovery and format inspection only; no credentials were used and no tool calls were made.

The distinction matters: discovering a remote tool definition is not the same as successfully executing that tool against a real service.

6. Current limitations

This release deliberately does not support:

  • Basic authentication.
  • OAuth2.
  • Other API-key authentication formats.
  • header_fields.
  • OpenAPI conversion.
  • Variable substitution.
  • Multi-tenant UTCP hubs.

Tool schemas exceeding max_schema_chars are also still skipped.

These limitations are intentional boundaries, not capabilities we want users to assume are already available.

7. Why this matters for RagLeap

RagLeap is an open-source, self-hosted AI employee platform.

Its approach is built around controlled autonomy: AI employees can propose actions, but important operations remain subject to owner-defined permissions and approval boundaries.

Remote tool integration must follow the same philosophy.

Adding more integrations is useful. Making sure those integrations operate within explicit boundaries is equally important.

We want RagLeap to grow as an ecosystem where developers can build capabilities without weakening the security and control model.

8. Try it

Install the release:

pip install ragleap-integrations==0.5.0
Enter fullscreen mode Exit fullscreen mode

For the optional security extra:

pip install "ragleap-integrations[security]==0.5.0"
Enter fullscreen mode Exit fullscreen mode

Explore the source code:

Help us build RagLeap

RagLeap is fully open-source and self-hosted. We welcome developers, researchers, and companies interested in contributing practical integrations, improving security, testing edge cases, and expanding the ecosystem.

Contributions are reviewed through the normal GitHub pull request and CI process.

If you are interested in building controlled AI tool integrations, explore the repository and join us.

RagLeap — Open-source AI employees that ask before they act.

GitHub: https://github.com/ragleap/ragleap-core

Website: https://ragleap.com

Top comments (0)