Problem
Eve has a filesystem-first override model: a production agent removes an unwanted built-in by adding a same-slug module that exports disableTool().
That is default-allow. An Eve dependency upgrade can expand a production agent capability surface when the framework adds a built-in, unless every consuming application already knows to add the matching tombstone module. This is risky for filesystem, shell, network, delegation, and skill-loading tools.
Filesystem discovery is a good implementation and convention layer, but it should not be the sole production authorization boundary.
Proposal
Add a declarative built-in tool policy to defineAgent with explicit allowlist mode.
Example API:
export default defineAgent({
model: "openai/gpt-5.6",
builtInTools: {
mode: "allowlist",
allow: ["ask_question", "todo", "web_fetch", "load_skill"],
},
});
Desired behavior:
- In allowlist mode, a framework built-in is unavailable unless named in allow.
- Authored tools and explicit same-slug wrappers or overrides continue to work normally.
- The compiled manifest and Eve info endpoint clearly show effective built-in policy and final tool surface.
- A framework upgrade that introduces a new built-in cannot silently grant it to an allowlisted production agent.
- Current behavior remains the backward-compatible default with a clear migration path.
A denylist API could also work, but an allowlist is the safer production primitive.
Current workaround
We snapshot-test the public eve/tools/defaults export surface in CI and review every change. That helps, but it is incomplete as a framework guarantee: it depends on consumers maintaining a separate inventory, and not every conditional framework built-in is necessarily represented by that module.
Happy to help test or contribute an implementation.
Problem
Eve has a filesystem-first override model: a production agent removes an unwanted built-in by adding a same-slug module that exports disableTool().
That is default-allow. An Eve dependency upgrade can expand a production agent capability surface when the framework adds a built-in, unless every consuming application already knows to add the matching tombstone module. This is risky for filesystem, shell, network, delegation, and skill-loading tools.
Filesystem discovery is a good implementation and convention layer, but it should not be the sole production authorization boundary.
Proposal
Add a declarative built-in tool policy to defineAgent with explicit allowlist mode.
Example API:
Desired behavior:
A denylist API could also work, but an allowlist is the safer production primitive.
Current workaround
We snapshot-test the public eve/tools/defaults export surface in CI and review every change. That helps, but it is incomplete as a framework guarantee: it depends on consumers maintaining a separate inventory, and not every conditional framework built-in is necessarily represented by that module.
Happy to help test or contribute an implementation.