flex-auth had no image workflow, so its production images were hand-built
on a workstation and pushed with workstation credentials -- an artifact
whose provenance was someone's working tree rather than a forge revision.
Ports activity-core's canonical image.yaml: the container-build runner
fetches a tarball of the pushed commit, builds, and pushes :latest and
:main-<short-sha>, then reports the immutable digest for the rollout step.
examples/** is a build-trigger path on purpose -- policy packages are
COPYed into the image and there is no hot reload, so a policy change is
an image change.
Runbook updated to say plainly that images are not built on workstations.
FLEX-WP-0011 filed for the rest of the gap: flex-auth runs two production
Deployments on railiance01 but has never been brought under the
staged-promotion contract (RAIL-BS-WP-0006). No railiance/app.toml, no
stage commands, no canary or approval evidence; the deploy/ directory is
a rescue of specs that existed nowhere, not the sanctioned overlay shape.
Pre-existing debt found during the FLEX-WP-0010 rollout, not a regression
from it, and not a blocker for routine policy rollouts -- flex-auth fails
closed. T03 also flags that the coulombcore drain plan still lists
flex-auth on a host it no longer runs on.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The two flex-auth Deployments were applied from a YAML file that lived
outside this repo, so the only surviving copy of their authored spec was
the last-applied-configuration annotation on the live objects. That made
rollback depend on a cluster annotation -- recovered them into deploy/
before the FLEX-WP-0010 rollout rather than after an incident.
Covers Deployment, Service, and the default-deny NetworkPolicy for both
flex-auth-tenant-engine and flex-auth-user-engine. Verified with
kubectl apply --dry-run=server: Deployments and Services round-trip as
unchanged. The NetworkPolicies report "configured" because the manifests
keep an explicit egress: [] that the API server normalises away -- same
deny-all semantics, documented so nobody chases it.
The runbook records that policy packages are baked into the image with no
hot reload, that both Deployments share one image repo at deliberately
different digests (so roll only the one whose policy changed), and pins
both last-known-good digests as rollback targets.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
FLEX-WP-0010-T04: the deployed flex-auth-tenant-engine Deployment bakes
the policy package into its image, so production still serves the
four-action policy -- probed live, tenant.retire returns deny
unknown_action there while tenant.create allows. TEN-WP-0005-T05 is
unblocked in source but needs an image build from 8e127e5 and a rollout,
which this workplan does not scope. Stated in the workplan and in
examples/tenant-engine/README.md rather than left implied.
FLEX-WP-0009-T04: replayed all six user-engine fixtures against the
deployed flex-auth-user-engine service; all six matched expected effect
and reason, confirming the deployed failure matrix is still fail-closed.
T04 stays in progress -- the criterion also requires user-engine to
retire its local bridge, which is not flex-auth's to close.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Extend the tenant-engine write-API policy package with tenant.update,
tenant.retire, and tenant.reactivate, the three actions TEN-WP-0005
introduced. Until now every lifecycle mutation resolved to deny
unknown_action, blocking TEN-WP-0005-T05 production rollout.
- policy_package.md: three actions in valid_actions and frontmatter;
CARING capabilities extended with EditAny/Archive/Restore
- protected_system_manifest.yaml, subject_manifest.yaml, and the rebuilt
registry_snapshot.json carry all seven actions
- docs/tenant-engine-action-vocabulary.md documents the HTTP surfaces
- 8 new fixture pairs and 5 new Rego tests, including action-drift
guards (tenant.retired, tenant_update -> unknown_action)
T02 decision, recorded in policy_package.md: tenant.retire does NOT get
stricter authorization yet. With one service subject and no assurance
claim in the CheckRequest there is nothing stricter to check, and a
condition the sole caller always satisfies would falsely read as
separate control. Retirement is reversible and non-destructive. Revisit
on KEY-WP-0005 assurance claims or a second operator subject.
Verified: 11/11 Rego tests, 16/16 fixtures, go test ./... green, gofmt
and go vet clean. End-to-end against a live serve with a real
tenant-engine through the unmodified FlexAuthWriteAuthorizer: update
6176c39c2f4d7b15, retire 8a801b8ee8455080, reactivate c64cf3713cecd970
all allow; unregistered actor denied unknown_subject
(59d3e99c6416be89, 403 write_denied).
Handoff revision for TEN-WP-0005-T05: package
tenant-engine.write-api.mutate v1 (ready, caring-0.4.0-rc2).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
TEN-WP-0005 added tenant.update / tenant.retire / tenant.reactivate to
tenant-engine's write API. FLEX-WP-0008's policy package predates them, so
every lifecycle mutation resolves to deny unknown_action -- correct
fail-closed, but it blocks TEN-WP-0005-T05 rollout and USER-WP-0021.
Requested by tenant-engine; action strings taken verbatim from the live
_RESOURCE_TYPES mapping.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Maintainer decision, 2026-07-29: adopts TRSL V1C1 as this repo's
preliminary governing license, per target-revenue's
workplans/TREV-WP-0008-governance-and-pilot-rollout.md T05. Full
specialist legal review is deferred until out of beta (target-revenue
SCOPE.md §1). No Phase is yet declared for this repo.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
QONTO-WP-0004-T04. Modeled directly on examples/tenant-engine/: one
resource type (finance-snapshot), one action (finance.qonto.read),
two registered subjects (an agent-harness session identity and the
founder's human identity), and a Rego policy gating on
resource.system + action + subject.type + tenant match. Tenant
capability-role/plan liveness (VEN/CUS) is deliberately NOT encoded
here -- that's qonto-assistant's separate tenant-engine live-lookup
check, per this package's own scope note.
Verified: flex-auth test-policy (6 rego tests + 6 fixtures, all pass),
load-registry, and CLI check for both an allow and a deny case. Also
verified end-to-end over real HTTP: a live flex-auth serve loaded with
this exact registry+policy, hit by qonto-assistant's actual
FlexAuthCheckClient (not a mock) -- allow for tenant:friendly:binky,
deny (wrong_tenant) for a mismatched tenant.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
internal/adapters/tenantengine: HTTPClient.LiveRoles() calls tenant-engine's
GET /tenants/{id}/roles/live. LiveRolesResult.Available is the load-bearing
field -- false on any transport error, non-200, or malformed body, never
inferred as zero roles. AttachToContext() writes both tenant_roles and
tenant_roles_available into a CheckRequest.Context map; a consuming Rego
policy must check tenant_roles_available before trusting tenant_roles.
Architectural finding recorded in the workplan: engine.go's Check() has no
context-adapter hook, and none of the existing topaz/relationship/rule
adapters are wired into cmd/flex-auth either -- they're standalone packages
for downstream composition. This adapter is a request-preparation helper a
protected system's own request-building code calls before POST /v1/check,
not an engine-internal hook, matching that precedent exactly.
9 Go tests; gofmt/vet/build clean; go test ./... green repo-wide.
Verified as a real three-service chain: live flex-auth serve + live
tenant-engine, created a tenant and granted it a CUS role through the real
flex-auth-gated write path, then read it back through this adapter (via a
throwaway harness, not committed) -- known tenant: roles=[CUS]
available=true; unknown tenant: roles=[] available=false err="status 404".
FLEX-WP-0008 closed: T01-T04 all done. tenant-engine's write path is now
real end-to-end; any other protected system can pull live tenant capability
role context, fail-closed. Remaining open item unchanged from TEN-WP-0003:
KEY-WP-0005 (key-cape's IAM Profile core-claims gap).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
docs/tenant-engine-{resource-namespace,action-vocabulary}.md: four actions
(tenant.create, tenant.role.grant, tenant.role.revoke, tenant.plan.assign)
matching tenant_engine/src/tenant_engine/authz.py's _RESOURCE_TYPES mapping
exactly. No resource_manifest.yaml -- tenant-engine's resources are created
dynamically, unlike ops-warden's fixed SSH-certificate inventory; documented
as a deliberate deviation.
examples/tenant-engine/: protected_system_manifest.yaml, subject_manifest.yaml
(one registered caller: tenant-engine's own service identity),
policy_package.md (Rego rules + embedded tests), policy_fixtures.yaml (8
allow/deny pairs), assembled registry_snapshot.json, two standalone
check_request examples, README.
Design decision made explicit in the workplan: operator/service-identity
authorization (one known subject, four known actions), not aal2+assurance +
tenant-capability-role checking -- CheckRequest carries no assurance claim
yet (TEN-WP-0003 already flagged actor as a plain request-body field, not a
real auth context), and a tenant's capability roles are the tenant's own
state, not a property of who may call tenant-engine's admin API. Revisit
once KEY-WP-0005 gives callers a real assurance-bearing identity.
Verified for real: built ./cmd/flex-auth, ran test-policy (6 tests + 8
fixtures, all pass), load-registry, check against both example requests.
Then ran a live flex-auth serve with this exact registry+policy and pointed
tenant-engine's real, unmodified FlexAuthCheckClient/FlexAuthWriteAuthorizer
at it over real HTTP: unknown subject -> 403, tenant-engine -> 201. go test
./... still green across the whole repo.
T03 (live-lookup context adapter for other protected systems) stays open --
new Go adapter package, tracked separately.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Registers tenant-engine as a flex-auth protected-system consumer in both
directions its boundary contract requires: tenant-engine's writes need
authorization (FlexAuthWriteAuthorizer in TEN-WP-0003 currently gets
deny/not_applicable for everything until a policy package exists), and
flex-auth's own decisions for other protected systems need tenant
capability roles as context input via a live-lookup adapter.
Scoped closer to FLEX-WP-0006/0007 (ops-warden's small security-lane
integration) than FLEX-WP-0003 (Markitect's CARING-benchmark integration)
-- tenant-engine's resource/action vocabulary is small.
Registered, not implemented.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Sync AGENTS.md, CLAUDE.md, and .claude/rules from updated project_rules
templates: workplan-first session protocol, legacy terminology footnote,
and GET /workplans/ examples.
Correct a stale Current State paragraph: FLEX-WP-0002 (standalone core),
0003 (Markitect integration), and 0004 (delegated PDP/directory adapters)
were completed in May 2026, not "planned". Record FLEX-WP-0007 closure:
ops-warden ran the joint OpenBao smoke (2026-06-29, decision
032b096c433ad80c allow; ttl_out_of_bounds deny), with production
policy.enabled deliberately left off while the ecosystem is build-stage.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
ops-warden's SSH signing policy gate (FLEX-WP-0006 finished, FLEX-WP-0007
deploying) makes it flex-auth's first shipped protected-system consumer.
Update the intent baseline to match the implemented reality:
- SCOPE Current State: standalone Go core + /v1/check is implemented;
FLEX-WP-0001/0005/0006 complete, 0007 blocked only on T4 VAULT_TOKEN.
- SCOPE Related/Overlapping + Disjoint From: ops-warden is now a consumer,
not merely disjoint; the once-hypothetical "agt as flex-auth subject"
flow is realized through the signing gate. Disjointness narrowed to the
identity surface (warden issues certs, flex-auth never does).
- INTENT Consumer Patterns: lead with the shipped action-gate shape
(ops-warden), keep Markitect as the planned knowledge-pipeline consumer.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Add production_registry_snapshot.json from ops-warden inventory with CI
coverage for real actors, IAM subject binding, ttl_out_of_bounds, and
unknown_actor_resource. Extend serve contract tests with /healthz and
publish the registry sync contract for operator deployment.
- Align agent files with on-disk workplan prefixes (infer from workplan ids)
- Set workplan domain to registered domain_slug; add topic_slug where applicable
- Repair frontmatter delimiter formatting; migrate legacy task status literals
- Regenerate AGENTS.md, CLAUDE.md, and .claude/rules from State Hub templates
Remove external reference points so the intent stands on its own at the
abstract, stable level: drop named identity/SSO systems, named PDP/policy
products, named directory/enterprise systems, the named first-consumer
project, and the external IAM-profile path. Keep all of flex-auth's own
substance — purpose, responsibility boundary (stated as abstract roles:
identity layer / authorization / enforcement points), design principles,
concepts, API shape, standalone vs delegated mode, non-goals, early work.
Relationships to other systems belong in interface contracts and the
orchestration responsibility map, not in intent.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
