00 — Inventory of existing materials

Scope: everything in /home/user/Project-Agent that bears on the six-capability control-plane thesis. The repo holds (a) a working FastAPI backend, (b) an MCP server, (c) ~18 in-product UI mockups, (d) a marketing site with substantial docs, (e) blog posts and case material that frames the market thesis. There is no patent disclosure or formal whitepaper. There is a recently-written internal build plan (/root/.claude/plans/what-tools-in-arx-glimmering-tiger.md) generated against the Cisco productivity case; treat it as a prior internal evaluation, not as ground truth.

Assumption: the arxsec-api/ tree is the actual baseline (real Python code). The arxsec/ directory is shared marketing/in-product CSS only — not a code system. Falsifiable by find arxsec/ -name "*.py" | wc -l (returns 0).

---

1. Backend: arxsec-api/

FastAPI + Supabase (Postgres + RLS) + Redis + Celery + Docker executor. ~14,800 LOC across 27 v1 routers.

1a. Capability surface present today

| Capability | Module | Implementation depth | |---|---|---| | Agent CRUD + lifecycle (deploy / suspend / rollback / version) | app/api/v1/agents.py | Real. Suspend = status flag (no cascade). | | Declared-intent manifest (per-agent) | app/api/v1/agents.py (set_agent_intent), docs/governance/intent-manifests.md | Real. JSON column on agent. Schema = permitted_systems, permitted_actions, permitted_data_types, max_frequency. INV-003. | | Drift detector (4 drift types, Celery 15-min) | app/core/drift_detector.py | Real. Detects unauthorized_system, unauthorized_action, frequency_exceeded, unauthorized_data_type. INV-003. | | Approval queue + risk scoring + Slack/email notifier | app/api/v1/approvals.py, app/core/risk_scorer.py, app/core/approval_notifier.py | Real. Single-tier approver only — no multi-level escalation chain. | | Immutable audit (SHA256 hash per entry, append-only DB constraints, SIEM fan-out, CSV export) | app/audit.py, app/integrations/siem.py | Real. INV-001. Hash chain is per-entry SHA256, not Merkle/anchored. No external timestamp authority. No customer-controlled S3 destination. | | Policy engine + intercept layer | app/core/policy_engine.py, app/core/intercept.py, app/connectors/base.py | Real. Hand-coded Python verdict logic (PERMIT / ESCALATE / DENY). Not OPA/Cedar/Rego. No policy-bundle hot-reload. INV-002. | | Compliance package generator + PDF | app/core/compliance_generator.py (1,584 LOC), app/compliance/mapper.py | Real for SOC 2 (8 control mappings), OWASP Agentic, OWASP LLM Top 10, NIST AI RMF (control-list level only — no source-line attribution, no release SHA pinning). | | Vault abstraction (9 providers) | app/vault.py, app/api/v1/vault_config.py | Real. HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, Akeyless, Doppler, Infisical, CyberArk Conjur, Keeper. | | Scoped credential binding per agent | app/core/credential_binder.py | Real. INV-005. Revoke is per-(agent, connector_type) — not resource-scoped (e.g., "github.repo:org/foo"). Cascade revoke across all of an agent's bindings is not implemented. | | 105 connectors (security, identity, ITSM, SIEM, EDR, vault, cloud) | app/connectors/*.py | Real. Strong on security stack; thin on commercial-platform agent fabrics (no Salesforce, Workday, Microsoft Foundry, Bedrock AgentCore, ServiceNow AI Agents, UiPath, watsonx Orchestrate). | | LLM router with circuit breaker + per-org credential resolution + per-attempt audit | app/llm/router.py | Real. Two providers wired (Anthropic, OpenAI). Tier-resolved (frontier/mid/cheap). | | MCP token service (issuance + revocation) | app/services/mcp_token_service.py | Real. Token revocation marks revoked_at; auth filter excludes revoked. No standardized agent-identity claims. | | Cloud asset discovery (AWS, Azure, GCP, Kubernetes) | app/inventory/discovery.py, app/inventory/providers.py | Real for cloud assets. Does not discover commercial-platform agents (Agentforce/Foundry/Gemini/Bedrock/ServiceNow/UiPath/watsonx). | | eBPF executor (Intune-routed Windows enforcement, K8s daemonset hooks) | app/runtime/ebpf_executor.py, app/inventory/intune_ebpf.py | Partial. Routes to Intune connector; "local eBPF agent" path is declared but not implemented. | | Multi-tenant via Supabase RLS | app/database.py + Supabase policies | Real. Per-org isolation enforced at row level. | | Sandbox runtime (Docker, resource limits per plan) | app/runtime/sandbox.py, app/runtime/executor.py | Real for self-managed agent runtimes. Not a sidecar/proxy for foreign agent platforms. | | RBAC middleware | app/middleware/rbac.py, app/core/rbac.py | Real. Roles: admin / deployer / auditor / viewer + custom. | | SAML 2.0 + SCIM 2.0 + OIDC for human admins | app/api/v1/saml.py, app/api/v1/scim.py, app/api/v1/sso.py, app/api/v1/auth.py | Real for human users. Not for non-human identities (NHI) at agent scale. | | LLM evaluation harness | app/llm/eval/ | Skeletal. | | Sync engine + adapters for ITSM (Jira, ServiceNow) | app/integrations/sync/ | Skeletal. Adapters exist; conflict resolver thin. |

1b. The five "INV-00x" invariants

The codebase repeatedly cites five product invariants. Confirmed in source + docs:

• INV-001 Immutable audit logging — every action emits an audit row, append-only.
• INV-002 Intercept pattern — every connector call goes through BaseConnector.execute(); policy engine has no bypass.
• INV-003 Declared intent + drift detection — every agent has an intent manifest, drift detector compares behavior against it on a 15-min cadence.
• INV-004 Flow tracing — multi-step agent flows tracked with a flow ID joined across audit rows.
• INV-005 Credential injection / scoped binding — agents never hold connector credentials; ARX injects at execute time from the vault.

These are real engineering invariants enforced in code, not marketing claims.

---

2. MCP server: arx-mcp-server/

Standalone MCP server (arx-mcp-server/main.py) that wraps the ARX API as MCP tools.

Tools exposed: run_security_scan, execute_remediation, check_compliance, manage_secrets, request_approval, get_audit_log, list_connectors, manage_policies. Plus a separate OpenAI-compatible HTTP shim (openai_server.py) and adapter (openai_adapter.py).

This is the production version of the "ARX as a tool the customer's agent calls" pattern. It is not a generic-MCP-gateway that intercepts MCP calls between an external agent and an external MCP server — it only proxies into ARX itself.

---

3. In-product UI surface

18 HTML pages under /home/user/Project-Agent/Arx *.html. Hardcoded demo data, but production-grade design system (arxsec/shared/inproduct.css + shell.js). Pages map to:

Operations: Admin (Overview), Agents, Agent Detail, Runs, Run Trace, Approvals, Approval Detail, Policies, Policy Editor, Connectors Admin, Connector Detail. Visibility: Audit, Compliance. Admin: Members, Secrets, Notifications, Settings, Onboarding.

Two new pages added in this evaluation cycle (consultant + board surfaces): Arx Engagement Canvas.html, Arx Board View.html.

No existing UI for: cohort/bulk onboarding, agent termination ceremony, drift triage queue, evidence-package builder, workforce dashboard, agent performance review, multi-tier approval routing.

---

4. Documentation site (docs/, docs-pages/, governance/, compliance/)

GitBook-quality. Notable architectural / governance documents:

• docs/getting-started/architecture.md — three-layer architecture (Agent runtime → Governance layer → Security tools), intercept pattern.
• docs/governance/intent-manifests.md — full schema + lifecycle for INV-003.
• docs/governance/policy-engine.md — verdict semantics (PERMIT/ESCALATE/DENY), enrichment as additive-only signal, no bypass.
• docs/governance/drift-detection.md, escalation-policy-matrix.md, risk-scoring.md, approval-gates.md, eu-ai-act-classification.md, ai-risk-policy.md.
• docs/governance/system-card-llm-router.md, system-card-mcp-server.md — public AI-feature system cards.
• docs/security/threat-model-llm-router.md, threat-model-mcp-server.md, ai-incident-response.md, supply-chain.md.
• docs/compliance/{soc2-mapping,audit-trail,evidence-export,packages,frameworks-coverage.csv,aiuc-1-readiness}.md.
• docs/admin/{auth-overview,auth-saml,auth-oidc,scim,rbac,api-keys,ip-allowlist,cmek,siem-export,webhooks}.md.

This is unusually mature documentation for a pre-Series-A company.

---

5. Marketing site

index.html, platform.html, solutions.html, connectors.html, maturity.html, maturity-assessment.html, integrations.html, blog/* (~17 posts), sla.html. Cream + Fraunces editorial design system distinct from in-product. Not relevant to this evaluation except as positioning signal.

---

6. Prior strategy material in the conversation

• The Cisco productivity case (10K layoff scenario, 19,900 governed agents, $1.92B annualized recovery, 78/113 SOC 2 controls auto-mapped). Provides the customer-outcome shape but does not specify the underlying technical mechanisms.
• The internal build plan at /root/.claude/plans/what-tools-in-arx-glimmering-tiger.md (this conversation, ~700 lines). Identifies gaps between current ARX and what the Cisco-shape outcome requires. Frames a 5-month build to Layer-1 completeness + 6–8 weeks per industry pack. Adds a Consulting Partner channel + Planning Dashboard + Board View.

That plan is internally written (no external review). Treat as input, not as gospel.

---

7. What is not in the materials

The thesis prompt assumes a vendor-neutral platform that governs agents on eleven foreign agent fabrics (Salesforce Agentforce, Microsoft Foundry/Copilot Studio, Google Gemini Enterprise Agent Platform, AWS Bedrock AgentCore, ServiceNow AI Agents, UiPath, IBM watsonx Orchestrate, LangChain/LangGraph, CrewAI, AutoGen, OpenAI Agents SDK). The current materials cover none of these eleven. Today's ARX governs:

• (a) agents that the customer wrote in Python and run inside ARX's own Docker sandbox (app/runtime/executor.py)
• (b) calls into 105 security/identity/cloud connectors

That is not the same product as the thesis describes. The current product is "governance for the customer's own internally-built agents that route through ARX." The thesis product is "governance for agents the customer didn't write and doesn't run, on platforms ARX doesn't control." That is a much harder problem and the current codebase does not begin to address it.

Other gaps relative to the thesis:

• No SPIFFE/SPIRE-style cryptographic agent identity. MCP tokens are opaque bearer tokens; no x509-SVID or JWT-SVID, no agent-attested workload identity.
• No OpenTelemetry GenAI semantic conventions emission (no gen_ai.* attributes on spans, no traces stitched across agents/tools/sub-agents).
• No A2A (Agent-to-Agent) protocol support of any kind.
• No Cedar / OPA policy language. Hand-coded Python verdict logic only.
• No customer-controlled S3 audit destination with externally verifiable hash chain.
• No FAPI 2.0 / OAuth 2.1 hardened token-exchange flow for agent credential issuance.
• No NHI-at-scale identity-issuer (today's MCP-token service is not designed for 10K agent-identities per tenant).
• No discovery for commercial agent fabrics — app/inventory/discovery.py enumerates cloud assets (EC2, S3, AKS, GKE, etc.), not Foundry agents or Agentforce flows.
• No kill-switch propagation across a foreign agent fabric. agents.suspend flips an internal status flag; nothing flows out to Foundry/Agentforce/etc.
• No vendor security questionnaire generator (SIG/CAIQ/HECVAT auto-fill).

---

8. Honest pushback

Where existing materials make claims the technical detail doesn't support:

1. "eBPF agent for kernel-level enforcement." app/inventory/intune_ebpf.py is named IntuneEBPFAgent, but the actual enforcement path is IntuneConnector API calls. The local eBPF agent is referenced as "Tier 2" but no eBPF program (BCC, libbpf, Cilium/Tetragon integration) is actually present. The naming overstates the implementation.

1. "Hash-chained personnel records / immutable audit." Audit rows have a SHA256 hash field, but no chain — each row's hash is independent. Tampering with a single row in the DB would not be detected by any chain-integrity check, because there isn't one. The Cisco-case claim of "Cisco's auditors verify chain integrity from infrastructure Cisco controls" is currently aspirational. The architecture for it (Merkle blocks anchored to customer S3 with RFC 3161 timestamps) is not built.

1. "Auto-mapped SOC 2 controls." compliance_generator.SOC2_CONTROL_MAP covers 8 action-types mapped to controls. The Cisco-case claim of "78 of 113 SOC 2 controls auto-mapped" is 10× over-stated relative to what's actually wired. The architecture supports it (the dictionary is straightforward to extend) but the mappings themselves are not present.

1. "Sub-100ms policy enforcement." No latency budget is documented or measured anywhere in the codebase. The intercept layer makes a synchronous call into the policy engine, which makes a Supabase query, which is a network round-trip. Realistic p99 is more likely 50–200ms today; nothing prevents it from being worse. There is no policy-bundle local cache, no in-process Rego/Cedar evaluator.

1. "Vendor-neutral cross-platform governance." The product today is platform-aware in exactly one direction: ARX wraps 105 destination tools. It does not intercept or govern agents running on Foundry/Agentforce/Gemini/Bedrock — those platforms don't even appear in the connector list. The marketing positioning anticipates a product that the engineering does not yet ship.

1. "100+ connectors." Confirmed at 105. Claim is accurate but their distribution is unbalanced — almost all are security/cloud/identity (CrowdStrike, Splunk, Okta, AWS, etc.), almost none are workflow systems (no Salesforce, no Workday, no SAP, no GitHub-write, no Slack-write-with-policy). The connector library is wide on the security stack and narrow on the systems agents would actually take action in.

These mismatches are normal at this stage of company maturity. They matter for this evaluation because the thesis assumes a level of platform breadth that the engineering does not yet have, and the gap-to-thesis is where the next 18 months goes.