Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Make the policy decision point pluggable (the rules are injectable, the evaluator is not)

Abierto
  • ¿Algo no está bien?
#350 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
typescript
Área
authorization, security

Línea de trabajo

Empieza por server/src/computer/gateway.ts alrededor de las líneas 469-535 y por server/src/computer/policy.ts alrededor de las líneas 4-12, 38-42, 44-153 y 210-243. Confirma si el gateway empresarial ya tiene un punto de decisión conectable y, a continuación, define y documenta el contrato del decider, conservando la resolución de snapshots, el manejo de dry-run, el orden de auditoría y el comportamiento fail-closed; se considera completado cuando incluye la ruta predeterminada y un decider de ejemplo desarrollado.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

What I see today

The policy data is already fully injectable. options.policy() is a getter
(server/src/computer/gateway.ts:523), backed by createPolicyStore with
ACTION_POLICY_TOPIC for live reload (server/src/computer/policy-store.ts).

The evaluator is not. evaluateActionPolicy is a direct import from ./policy,
called synchronously:

const decision = evaluateActionPolicy(options.policy(), context);

So a deployment can change the rules, but not who answers.

Why that's worth a seam

Three cases the current shape can't serve:

  1. A deployment that already owns a policy engine. OPA/Rego, Cedar, an internal
    service. Today they have to transcribe their rules into CEL and keep two sources in
    sync, which is exactly the setup where the two drift and nobody notices.

  2. Decisions that need state the gateway doesn't hold. "This bot has already
    submitted three orders today." "This action is above the amount this actor may
    approve alone." "A human granted this, twenty minutes ago, and the grant expires."
    CEL over a stateless PolicyContext can't express any of those — not a flaw in the
    expression language, just a different question.

  3. Decisions that take time. Anything involving a human in the loop is async by
    nature, and the current call site is synchronous.

The good news is that most of the work is already done: PolicyContext
(server/src/computer/policy.ts:44-153) is a clean, serialisable, effect-level
object — intent, mcp.effect, file.extension, command, resolved element. That
is a better PDP boundary than most systems that set out to build one.

Concrete shape

export type PolicyDecider = (
  context: PolicyContext,
) => PolicyDecision | Promise<PolicyDecision>;

Default stays exactly what happens now:

const decide: PolicyDecider = options.decide
  ?? ((ctx) => evaluateActionPolicy(options.policy(), ctx));
// ...
const decision = await decide(context);

Line 523 is already inside an async method that awaits write(...) on the next
line, so the await costs nothing structurally.

Two things I'd want written into the contract, not left to the implementer:

  • A decider that throws, or exceeds its timeout, is a refusal. Same discipline as
    matches() and its onError argument (policy.ts:210-243). A remote PDP that is
    merely unreachable must not be a way to get an action through, and the timeout should
    be required rather than optional.
  • dry-run stays in the gateway, not in the decider. Otherwise an external decider
    can silently disable enforcement for the whole deployment, which is the one thing this
    seam must not make possible.

What I would not touch

  • Snapshot resolution stays server-side (gateway.ts:469-471). A decider receives the
    element the server resolved, never what the caller claimed. The comment at
    policy.ts:38-42 is the reason the whole thing works and an external decider must not
    get a chance to weaken it.
  • The gateway still writes the audit row before forwarding (gateway.ts:524-535),
    whoever decided. The trail records the decision, not the decider's opinion of it.

One question before any of this

policy.ts:4-12 says this mirrors the policy engine in CopilotKit's enterprise agent
gateway, deliberately, so a rule means the same thing in both. Does that engine already
have a pluggable decision point — and if not, is divergence here something you'd rather
avoid? If so, say and I'll drop it; that's a good reason.

Otherwise I'm happy to send the PR: default path byte-for-byte unchanged, the type, the
fail-closed timeout, and one worked example decider.

Disclosure: I build an authorization service for agents, so an external PDP is
obviously useful to me. I've tried to write this as it would stand without that —
push back if it reads otherwise.

Lenguaje dominante
TypeScript
Estrellas
6.6k
Forks
914
Merge medio
19 h 22 min
PR fusionados (30 d)
140

Preparar el entorno

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Tiene una plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de CopilotKit/OpenBot

Todos los issues de CopilotKit/OpenBot

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.