What is the Neural Link?

The Neural Link is a bi-directional bridge that connects AI agents directly to the Neo.mjs runtime. It lets agents inspect the Scene Graph, component state, event listeners, computed styles, and DOM rectangles, and mutate the running application in real time.

Why is Neo.mjs called an Application Engine instead of a framework?

Neo.mjs maintains persistent application objects in a worker-backed Scene Graph instead of compiling application state away into ephemeral DOM nodes. That architecture enables multi-window orchestration, runtime permutation, and deep AI introspection.

What is Context Engineering?

Context Engineering shapes the information and tool environment around AI agents. Neo.mjs implements it through Knowledge Base, Memory Core, GitHub Workflow, and Neural Link MCP servers for frontier harnesses, plus a File System MCP server for internal Neo.ai.Agent local loops.

What is the Neo.mjs Agent OS?

The Neo.mjs Agent OS is the repository Brain: source code and services for Memory Core, Knowledge Base, Active Hybrid GraphRAG, DreamService, Golden Path synthesis, A2A coordination, and Neural Link tooling.

Frontmatter

id	12296
title	KB private owner read-back over OIDC/proxy: key ownership on userId (agentIdentityNodeId is null there)
state	Closed
labels	enhancementaiarchitecture
assignees	neo-opus-ada
createdAt	Jun 1, 2026, 10:30 AM
updatedAt	Jun 1, 2026, 10:36 AM
githubUrl	https://github.com/neomjs/neo/issues/12296
author	neo-opus-ada
commentsCount	1
parentIssue	null
subIssues	[]
subIssuesCompleted	0
subIssuesTotal	0
blockedBy	[]
blocking	[]
closedAt	Jun 1, 2026, 10:36 AM

KB private owner read-back over OIDC/proxy: key ownership on userId (agentIdentityNodeId is null there)

Closed Backlog/active-chunk-16 enhancementaiarchitecture

neo-opus-ada commented on Jun 1, 2026, 10:30 AM

Context

The KB read-side visibility work (PR #12290 / #12163) made private chunks owner-scoped, owner = the writer's getAgentIdentityNodeId(). That identity is populated in stdio / env / gh-cli contexts but not over the OIDC/proxy transport a cloud deployment uses (TransportService.mjs proxy path + AuthService.mjs OIDC path resolve a userId/username, never an agentIdentityNodeId).

The Problem

In an OIDC/proxy cloud deployment a private chunk has no resolvable owner on read, so it fails safe — hidden from everyone, including its writer. This closes the cross-user leak (the #12163 core threat) but leaves owner read-back inert in exactly the shared-default-tenant cloud scenario #12163 targets: a user cannot read their own private content back.

The Fix

Key per-chunk ownership on userId (the per-user identity the OIDC/proxy transport does populate, and which distinguishes users within a shared tenant) rather than agentIdentityNodeId. This requires aligning both sides:

Write: stamp the owner from the authenticated userId (with the agent-identity path preserved for local stdio agents, or unified on userId).
Read: match the ownership branch in readVisibilityFilter.mjs on normalizeUserId(getUserId()).
Re-validate the dockerized integration specs can then exercise owner read-back (an owner-stamped private chunk is returned to its writer and to nobody else).

Consider whether userId should be the single owner key for both transports, or a fallback chain (agentIdentityNodeId ?? userId) — resolve in the PR.

Acceptance Criteria

In an OIDC/proxy deployment, a user can read back their own private chunk; another user in the same shared tenant cannot.
Local stdio behavior preserved (agent-authored private content still owner-scoped).
Dockerized integration coverage for owner read-back over the OIDC transport (currently only the tenant axis is exercised end-to-end).
readVisibilityFilter.mjs JSDoc + cloud-deployment/Security.md updated to drop the "owner read-back not yet available over OIDC" limitation once delivered.

Completes the owner-scoping intent of the KB read-side visibility work (the leak-close + fail-safe shipped first; this restores owner read-back over OIDC).