Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#350 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
authorization, security

Direzione di ricerca

Inizia da server/src/computer/gateway.ts intorno alle righe 469-535 e da server/src/computer/policy.ts intorno alle righe 4-12, 38-42, 44-153 e 210-243. Verifica se l’enterprise gateway dispone già di un punto decisionale pluggable, quindi definisci e documenta il contratto del decider preservando la risoluzione degli snapshot, la gestione del dry-run, l’ordine degli audit e il comportamento fail-closed; il lavoro è completo quando include il percorso predefinito e un esempio di decider sviluppato.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
TypeScript
Stelle
6.6k
Fork
914
Merge medio
17h 52m
PR unite (30g)
155

Preparare l'ambiente

  • Include un Dockerfile o un file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di CopilotKit/OpenBot

Tutte le issue di CopilotKit/OpenBot

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.