FLEX-WP-0014. Package tenant-engine.write-api.mutate v1 now carries
nine actions: tenant.guardrail.read and tenant.guardrail.set on
resource type guardrail, verbatim from tenant-engine's mapping.
The read/write split is used now: flex-auth may read ceilings and is
denied action_not_granted on set; tenant-engine may do both. 17/17
Rego tests and 23/23 fixtures pass. Live e2e against a real
tenant-engine FlexAuthWriteAuthorizer matches.
In source only; production still serves the seven-action 9320df39 pin.
FLEX-WP-0013. Production had been rolled back to sha256:c25fc34a
(four actions), so tenant.update / tenant.retire / tenant.reactivate
denied unknown_action. Re-pin and apply the previously-live
sha256:9320df39 image (e9911eb). Live probe after restore: all seven
actions allow; misspelled action and unknown subject still deny.
user-engine pin unchanged. TEN-WP-0006 guardrail actions not added.
T04 is done: nine fixtures including registration-applicant match the
deployed /v1/check, user-engine is on the fail-closed HTTP adapter, and
the deploy manifest now pins the live digest.
Opens the State Hub capability request 893ff109, unanswered since
2026-07-02. Drafted as proposed/P3 rather than as the blocker it was
filed as, because two of its premises no longer hold:
- It is not blocking anyone. railiance-platform re-scoped and closed
RAILIANCE-WP-0005-T07 the same day it filed the request; WP-0005 is
finished and their grant catalog already enforces TTL, actor-type,
purpose and delivery-mode bounds locally. This buys defence in depth
and central decision records, not unblocking.
- The stated technical blocker is wrong. The request says the CARING
/v1/check schema cannot express TTL, purpose or delivery mode; the
ops-warden package in this repo already denies ttl_out_of_bounds by
reading input.context.ttl_hours against resource.attributes. CARING
constrains descriptor vocabulary, not the request payload.
The real gap is narrower: no credential-grant policy package exists, and
the helper's flat payload/response shape differs from CheckRequest. Its
endpoint path is configurable, so no bespoke endpoint is strictly
required. T01 makes the adapter-vs-consumer-mapping call an explicit,
jointly-agreed decision rather than a default.
Flags two things worth knowing before anyone implements: the helper sends
requested_ttl as a duration string while the ops-warden precedent compares
numeric hours (mis-parsing it would fail open on the check that matters
most), and without --require-flex-auth the helper continues by local
preauthorization when flex-auth is unreachable -- a different posture from
the tenant-engine and ops-warden gates.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
CI-built image from e9911eb, digest
sha256:9320df394a642eff24da8af4a0ee8886a7bb78b0f14d8ee1deeb30ea8eeeaba7,
verified in a throwaway container before pinning and then probed again
against the live Service after rollout:
tenant.retire allow write_api_policy_matched decision:491bbef2db999c02
tenant.create allow write_api_policy_matched decision:fa3ba90e9cccb5aa
tenant.retired deny unknown_action decision:c5ee185de439ffe5
unknown subject deny unknown_subject decision:a98c59c6a34f84ad
tenant.retire has flipped from deny unknown_action to allow in
production, which is what TEN-WP-0005-T05 was waiting on.
Only flex-auth-tenant-engine was rolled. flex-auth-user-engine stays
pinned to a31961c4 -- its policy is unchanged and there is no reason to
move it. Previous tenant-engine digest kept in the runbook as the
rollback target.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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
