RagLeap Core v0.13.3: Approval-Gated File Operations for AI Agents

AI agents that can read files are useful.

AI agents that can modify and delete files are more powerful.

But what happens when an agent modifies the wrong file, acts on outdated information, or executes a change the user never intended?

That is the engineering problem behind one of the main features in RagLeap Core v0.13.3.

Release: https://github.com/ragleap/ragleap-core/releases/tag/v0.13.3

What's new?

This release introduces three main areas of improvement:

Approval-gated file-writing and deletion.
Signed container images and supply-chain attestations.
Dependency and build-process updates.

Let's look at the important engineering details.

1. Approval-gated file writing

Two new operations are available:

write_file
delete_file

They operate only within folders explicitly granted write access.

The important part is the execution workflow.

Proposed change → Approval → Verification → Execution

The agent first proposes a specific operation.

The approval interface shows the owner what is about to happen, including a diff or relevant file details.

Before executing the operation, RagLeap checks the target file against the state captured during the preview.

This uses hash verification.

If the target has changed since the preview, the operation is refused.

This helps prevent an approved operation from silently being applied to a different file state.

2. Recovery through local trash

Previous file versions are preserved in .ragleap-trash inside the relevant folder.

Owners can manage recovery using local CLI commands:

ragleap files trash list ragleap files trash restore ragleap files trash empty

The agent cannot access this trash area.

This separation is important: an AI employee may propose a file operation, but recovery remains an owner-controlled capability.

3. Approval is still required in full autonomy mode

One design decision deserves particular attention.

Even when RagLeap is configured for full autonomy, file-writing and deletion operations still require owner approval.

The autonomy setting does not silently override the file-operation approval boundary.

Additionally, these capabilities are disabled by default.

Enabling them requires the relevant runner and application switches, along with an explicit write grant.

4. Broad folder access

RagLeap supports time-limited broad-folder grants.

These grants remain read-only.

Sensitive-looking filenames are filtered using name-based rules, not content-based inspection. This is a useful restriction, but it should not be mistaken for complete secret detection.

5. Signed images and software supply-chain improvements

The v0.13.3 release also brings improvements to container-image publishing:

Keyless signing with Cosign.
Build provenance attestations.
SBOM attestations.
CycloneDX SBOM generation.
Trivy vulnerability scanning.

A technical qualification:

The Trivy scan is currently report-only, not a blocking release gate. The workflow had one manual test run, and v0.13.3 is its first actual release-tag run.

Signing establishes the builder's identity; it does not establish that the image is free of vulnerabilities.

6. What we still need to improve

We don't consider these features a reason to stop security testing.

Independent security review and further failure-case testing remain important, particularly around approval enforcement, concurrent operations, file-system boundaries, and recovery behaviour.

We also distinguish file-operation capabilities from full desktop or browser control. They are not the same thing.

Why this matters

AI agent development is often discussed in terms of how many tools an agent can use.

We believe another question is equally important:

What prevents an agent from doing something it was never authorized to do?

At RagLeap, we're building open-source, self-hosted AI employees around controlled execution, explicit permissions, human approval, and accountability.

More capability should not mean less control.