Skip to content

fix: dual-Entity root cause — adapter tests use backend-aware imports#2

Merged
Aliipou merged 1 commit into
mainfrom
integration
Jun 1, 2026
Merged

fix: dual-Entity root cause — adapter tests use backend-aware imports#2
Aliipou merged 1 commit into
mainfrom
integration

Conversation

@Aliipou

@Aliipou Aliipou commented Jun 1, 2026

Copy link
Copy Markdown
Owner

Tests fed pure-Python Entity/Action into backend-aware adapters; under the Rust PyO3 backend that mixes type systems. Now import from authgate.kernel. Python mode unchanged (1167 passed).

🤖 Generated with Claude Code

…ual-Entity)

test_crewai_adapter + test_integration_e2e imported pure-Python Entity/Action/
verifier from authgate.kernel.{entities,registry,verifier} and fed them to the
backend-aware adapters. Under the Rust PyO3 backend that mixes type systems
('Entity cannot be converted to Entity'). Now import from authgate.kernel so the
types match whichever backend is active. Python mode unchanged: 1167 passed.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@Aliipou Aliipou merged commit 58fd039 into main Jun 1, 2026
11 checks passed
Aliipou pushed a commit that referenced this pull request Jun 20, 2026
…nce stack

WHY_NOT_OPA left ONE survivor (purpose-as-flow via capability+IFC). But IFC/data-gov
is itself crowded, so re-kill it against DLP / classification / lineage / PBAC /
confidential computing / IFC. Discipline: 'could agent data-flow matter?' (yes) is NOT
the question; 'what does AuthGate solve that DLP+lineage+PBAC+IFC do not?' is.

- Each incumbent mapped + its structural limit for AGENTS: DLP = content-at-egress, not
  capability/purpose-aware; classification = labels not enforcement; lineage =
  observability/batch not runtime-blocking; PBAC = query-time read, not cross-step flow;
  confidential computing = isolation, orthogonal; IFC = right mechanism but
  language-level + not capability-aware. All built for humans/ETL, not an agent moving
  data through an LLM context across tool calls.
- Candidate gap (narrow): capability-bound, runtime, per-tool-call IFC enforcement INSIDE
  the agent loop, label tied to the capability/purpose the data was read under, BLOCKED at
  the CallGate. AuthGate already has the 3 pieces in one runtime (capability DAG + IFC
  extension + CallGate); incumbents have them in different products at different layers.
- Held the discipline — 3 ways it still dies: (1) 'DLP with extra steps' (output-DLP
  catches the same); (2) PBAC + logging/detection is enough (runtime blocking = costly
  over-engineering); (3) DEEPEST: label propagation through an LLM is undecidable in
  general -> degrades to heuristic tainting ~ DLP. Risk #3 may be fatal alone.
- Probabilities (user's): new paradigm low; Agent Governance product notable;
  complementary capability on agentic AI most likely. More promising than FDK because the
  question is practical-2026, not philosophical.
- Sprint: 3 real agent scenarios that survive risks #1-#3; if they collapse to
  output-DLP+audit, close AuthGate; if one holds with SOUND label propagation, it has its
  single real reason to exist (agent data governance). Status: most promising of the
  three projects, still unproven.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Aliipou pushed a commit that referenced this pull request Jun 20, 2026
Apply the kill-discipline to the single surviving question: can a purpose/capability
label be carried usefully+reliably through an agent's execution (incl. LLM transforms)
to egress? Split it:

- A. SOUND fine-grained propagation (track meaning through the LLM): DEAD. LLM is not a
  transparent function; IFC needs a known program; no general answer to 'how much label
  remains' (SSN->summary->embedding->text). This is the FDK mistake in new costume.
- B. COARSE conservative tool-boundary propagation (label at capability/tool granularity;
  any P-tainted input -> output tainted P unless a declassifier ran; CallGate blocks
  off-purpose egress): ALIVE + buildable on existing pieces, reliable in the conservative
  sense.

The real crux is NOT soundness but LABEL-CREEP: conservative taint over-approximates ->
after a few steps everything is tainted -> blocks all egress -> 'sound but useless'. So
the deciding question is empirical+measurable: does coarse capability-taint catch real
purpose-violations WITHOUT over-blocking legitimate work (given a few declassifiers)?
High TP + tolerable FP -> real product; label-creep dominates -> DLP-renamed -> close.

Honest competition: capability+flow-control for LLM agents is exactly where frontier work
is moving (DeepMind CaMeL, dual-LLM, agent taint-tracking) -> validates the problem as
real (unlike FDK) BUT means AuthGate isn't first; must answer 'what over CaMeL?' (likely
deployable runtime gate + DAG + audit = engineering, not new idea).

Probabilities (user): paradigm <10%; fundamental research 10-20%; Agent-Governance
product 40-60%; distributed-systems+security showcase 80%+.

Sprint fully specified: Gate 1 (no code) = 3 scenarios survive risks #1-#2; Gate 2 (the
decider, needs a MINIMAL prototype) = coarse capability-taint at the CallGate, run on real
agent traces, MEASURE true-positive vs label-creep. That one measurement decides
product-vs-DLP. Status: most promising of the 3, still unproven, reduced to one
buildable+measurable experiment.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants