Validate the execution-enforcement wedge against native guardrails and existing authz

[dgenio]

Goal

Falsify or validate Weaver Kernel's revised product wedge before broad framework expansion:

Authorize elsewhere if you want. Weaver Kernel turns a decision into narrowly scoped executable authority, mediates the supported action path, bounds the result, and leaves an inspectable receipt.

This is a product experiment, not a marketing exercise. The desired outcome is evidence that tells us to proceed, narrow, or reposition.

Why

The agent-authorization/security category is no longer empty. Native framework permissions/approvals and dedicated authorization products can already solve meaningful parts of the problem. Kernel should not grow on the assumption that “authorization for agents” is automatically a differentiated category.

The core question is:

After existing framework/IAM controls are enabled, what security/operational job still makes an independent adopter choose Kernel?

Validation matrix

Integrate Kernel into at least three realistic applications that were not designed around the Kernel architecture.

Test at least two candidate beachheads:

1. coding agent — repo read/edit/test/publish boundaries;
2. application/workflow agent — tenant/resource/action constraints around business tools.

For every integration compare:

• framework-native permissions / approvals / middleware alone;
• existing IAM/policy check alone where applicable;
• Kernel added as the execution/evidence boundary.

Record:

• architectural changes required;
• lines/configuration needed for first useful denial;
• which execution surfaces are actually mediated;
• capability/resource/argument scoping that native controls can/cannot express;
• audit/evidence differences;
• false-deny/usability friction;
• bypass surfaces;
• latency overhead;
• what the adopter would remove if Kernel disappeared.

Independent-user test

Recruit at least three developers outside the maintainer's own implementation loop. Hands-on integration help is allowed; leading them to the desired conclusion is not.

After using the integration, ask each developer to explain in their own words:

1. what Kernel does;
2. why they would or would not keep it;
3. why framework-native controls / normal IAM were insufficient (if they were);
4. which part is most valuable: scoped grants, mediation, bounded output, receipts/audit, portability, or something else;
5. what adoption cost is unacceptable.

Store anonymized findings in a short repo artifact or linked discussion.

Exit criteria

Proceed with the current wedge only if:

• three independent developers can explain a concrete reason to use Kernel rather than only native framework permissions / a normal authz check;
• at least two realistic integrations demonstrate a material enforcement/evidence advantage;
• the advantage does not depend on adopting the entire Weaver Stack;
• the useful guarantee can be stated without implying complete mediation where it does not exist;
• the integration cost is compatible with the dx: framework middleware / drop-in mode (wrap an existing tool loop, don't rebuild the agent) #104 drop-in direction.

Kill / reposition signals

Reposition if any of these dominate the evidence:

• native framework controls are consistently sufficient;
• Kernel adds little beyond a normal middleware callback;
• exact-action/resource binding makes the API much more complex than the value delivered;
• users primarily want an out-of-process AgentFence/gateway boundary instead;
• three independent users cannot be obtained despite hands-on integration support.

Deliverable

A concise evidence report with:

• integration matrix;
• user findings;
• strongest pro-Kernel and anti-Kernel cases;
• recommendation: proceed / narrow / reposition / stop;
• backlog changes that follow from the evidence.

Sequencing

This is Gate 0 in the adoption-gated roadmap introduced by PR #276. It should run in parallel with security-contract hardening, but it should complete before multiplying framework adapters or starting late-stage ecosystem features.