Identities and Effective Authority

Enterprise problem: An enterprise user can be correctly logged in while an agent still acts with the wrong team, connector, or downstream identity, causing cross-team disclosure or an unauditable external change.

Whole-course context: Days 01–03 produced an owned agent version, a private generated-application boundary, and an admin-provisioned connector grant; today names the separate principals behind those artifacts so none silently inherits another’s authority.

Today’s slice: We model the distinct principals and derive effective authority across the provider control plane, hosted runtime, generated-application plane, and source-owned enterprise systems without granting any cross-plane access implicitly.

End-of-day evidence: A reviewer receives an identity-context contract, an allow/deny decision matrix, and linked records that make every authority input independently revocable and traceable.

Still unsolved: Enterprise login, active-team selection, run-token issuance, per-call connector authorization, human approvals, and mid-run revocation are deliberately deferred.

An ambiguous principal lets authority leak between people, teams, workloads, and external accounts; the consequence is that even a syntactically valid request cannot be shown safe.

Authentication (authN) proves who or what an actor is, while authorization (authZ) decides whether that actor may perform a specific action on a specific resource. An enterprise agent execution needs both, but authentication alone never supplies the missing resource, team, or purpose constraints.

Use case ID	Actor	Customer job	Success outcome	Denial or recovery evidence
D04-UC-01	Security architect	Define every identity participating in an agent run	A canonical context names organization, active team, human subject, immutable agent version, deployment, runtime workload, connector instance, tool, and downstream principal	A context missing or contradicting a required dimension is rejected with the absent field and a decision ID
D04-UC-02	Authorization service owner	Decide a requested action from the intersection of current grants	The same policy input deterministically produces least-privilege allow or deny and never unions unrelated team authority	Removing any required grant flips the result to deny while an unrelated positive control remains allowed
D04-UC-03	Enterprise auditor	Reconstruct who caused an external action and under which authority	One evidence envelope links human, agent, workload, connector, downstream resource, policy revision, and outcome	A broken delegation link or unexplained cross-plane reference fails the audit query and opens a containment case

The platform must keep at least these identities distinct:

Identity	Example	What it proves	What it does not prove
Organization	org_acme	Customer tenancy	Membership in any team
Active team	team_marketing	Operational security boundary selected for this request	Permission to use every Marketing resource
Human subject	user_8472	Account tied to the enterprise identity subject	Current team membership or agent permission
Agent version	agent_campaign_launch at v17	Immutable logic and declared capability requirements	A concrete credential or deployment approval
Deployment	deploy_marketing_prod	Version-to-team and environment binding	Authority in another team or environment
Runtime workload	spiffe://platform.example/ns/agents/sa/runtime	Attested software workload	Human delegation or business permission
Connector identity	connector_google_sheets_marketing	Approved integration instance and credential selection boundary	Access to every spreadsheet
Downstream principal	Marketing automation service account or the current user	Identity seen by the external provider	Platform permission to propose the action

Two invariants follow:

Human identity
!= team membership
!= agent identity
!= runtime identity
!= connector credential
!= downstream resource permission

Sharing agent logic must never share its creator's authority.

Broad roles hide which accountable actor needs which proof, so failures become policy debates instead of observable tests and unsafe access survives review.

Story ID	Use case IDs	User story	Observable acceptance conditions
D04-US-01	D04-UC-01	As a security architect, I want each principal carried as a separate typed field, so that no service can silently substitute creator, team, workload, or connector authority	A complete context validates; removing team_id or changing deployment_id to another team yields a named deny reason and immutable decision ID
D04-US-02	D04-UC-02	As a platform authorization service owner, I want authority calculated as an intersection, so that one permissive layer cannot override a denial at another layer	Table-driven tests remove each conjunct in turn, observe deny, and retain an allowed unrelated request as a positive control
D04-US-03	D04-UC-03	As a security auditor, I want a causal delegation chain, so that I can attribute an external side effect to a human, agent version, workload, decision, and downstream identity	A query by external request ID returns every linked principal and policy revision; a deliberately broken link is detected rather than inferred

The six core identities are not aliases for each other. The human initiates work, the team bounds the operating context, the immutable version declares requirements, the deployment supplies environment-specific bindings, the workload authenticates code in motion, and the external principal is independently authorized by the downstream system.

A useful normalized context is explicit rather than compressed into a generic user_id:

{
  "organization_id": "org_acme",
  "team_id": "team_marketing",
  "subject_id": "user_8472",
  "agent_id": "agent_campaign_launch",
  "agent_version": "v17",
  "deployment_id": "deploy_marketing_prod",
  "run_id": "run_01K1HZH8",
  "workload_identity": "spiffe://platform.example/ns/agents/sa/runtime",
  "connector_instance_id": "connector_google_sheets_marketing",
  "tool_id": "google_sheets.append_rows"
}

The context is descriptive, not self-authorizing. Every service validates the fields it consumes against its authoritative store; it does not trust a caller merely because the caller supplied plausible identifiers.

If a customer-visible action cannot be traced from selection through decision to observable outcome, a mistaken allow and a correct deny look identical and the operator cannot recover safely.

Flow ID	Use case IDs	Path	Trigger	Numbered steps	Terminal evidence
D04-FLOW-01	D04-UC-01	Happy	An architect submits the canonical identity-context example for validation	1. Parse typed principal fields.<br>2. Resolve each opaque identifier in its owning plane.<br>3. Verify organization and team consistency.<br>4. Persist the validated context digest.	Evidence records actor user_8472, resource identity-context, scope team_marketing, precondition all dimensions present, expected valid, observed valid, environment design-lab, timestamp, and immutable validation-run ID
D04-FLOW-02	D04-UC-02	Denied	A policy owner evaluates a run after the team grant is removed	1. Load current subject, team, version, deployment, connector, and risk facts.<br>2. Evaluate every conjunct without short-circuiting evidence collection.<br>3. Deny on missing current membership.<br>4. Evaluate an unrelated Engineering request as a positive control.	Evidence records the actor, requested agent resource, removed team scope, expected deny, observed deny, positive-control result, environment, timestamp, policy revision, and immutable decision ID
D04-FLOW-03	D04-UC-03	Recovery	An auditor selects a suspicious downstream change from the event explorer	1. Resolve the external request to a capability decision.<br>2. Follow links to run, deployment, version, team, subject, and workload.<br>3. Detect a missing connector-decision link.<br>4. Mark the chain incomplete and open containment.	Evidence records auditor, downstream resource, investigated scope, precondition external request exists, expected complete chain, observed missing link, environment, timestamp, and immutable case and trace IDs

The effective-authority rule is an intersection, not a role union:

Effective authority =
    current human authority
  INTERSECT selected-team authority
  INTERSECT immutable agent-version capabilities
  INTERSECT deployment bindings
  INTERSECT connector team policy
  INTERSECT credential scopes
  INTERSECT tool and argument policy
  INTERSECT downstream resource permissions
  INTERSECT runtime risk controls

If any set excludes the action, the result is deny. A broad organization role cannot repair a missing deployment binding, a team grant cannot widen an OAuth scope, and a downstream permission cannot make a model proposal authoritative.

Placing all trust in one token or gateway creates a security single point of failure; compromise or staleness there would grant every downstream capability without an independent check.

Use case ID	Entry point	Responsible services	Authoritative store	Failure evidence
D04-UC-01	Identity-context contract validator	Context validator resolves provider identifiers; workload verifier validates runtime identity; connector registry resolves integration references	Identity and membership store owned by Membership Service, Agent Registry owned by Agent Control Plane, workload trust store owned by Runtime Identity, connector registry owned by Integration Control Plane	missing_identity_dimension, cross_org_reference, or untrusted_workload, with validation-run ID
D04-UC-02	Policy simulation endpoint	Policy Decision Point loads current facts; resource-owning services answer existence and status; evidence writer persists all conjunct results	Versioned authorization-policy store owned by Policy Service plus current grants in each resource owner's store	required_conjunct_false, policy revision, fact versions, decision ID, and unaffected positive-control decision
D04-UC-03	Audit delegation-chain explorer	Audit Query Service joins immutable evidence references; plane owners verify opaque links; Incident Service contains incomplete chains	Append-only authorization evidence store owned by Audit Service and source audit logs retained by each downstream provider	delegation_chain_incomplete, missing edge type, trace ID, and containment-case ID

The boundaries remain independent:

• The provider control plane owns organizations, teams, memberships, agent metadata, deployments, policy, and provider audit.
• The hosted-runtime boundary owns workload identity and isolated execution; workload trust proves software identity, not user permission.
• The generated-application plane owns its application tenants, end users, sessions, domain roles, and data predicates when a generated app exists.
• The enterprise source system owns its accounts, resources, access-control lists, and final allow or deny.

Cross-plane identifiers are opaque references. Resolving one proves that the referenced record exists; it does not transfer the referenced plane's authority.

If principal state is duplicated into one convenient database, revocation and deletion diverge between owners and stale copies can continue authorizing sensitive work.

Generated-application database: Not created in this slice — identity separation and authority evaluation require durable provider control-plane and evidence records, while any future generated app must own its tenants, users, roles, sessions, and domain data separately.

Record or entity	Store and owner	Primary key	Foreign key or opaque reference	Tenant key	Material constraint	Lifecycle and deletion	Use case IDs
Organization	Identity and membership store; Membership Service	organization_id	None — organization is the provider tenant root	organization_id	Status gates every child decision; membership revision increases monotonically	Created on onboarding; suspended before closure; retained per enterprise contract; deleted or tombstoned after dependent retention periods	D04-UC-01, D04-UC-02
TeamMembership	Identity and membership store; Membership Service	(team_id, subject_id)	Local foreign keys to Team and User	organization_id	One current state and monotonic version per user-team pair; team and user must share organization	Provisioned or updated by admin/SCIM; revoked immediately; decision-relevant tombstone retained for audit; personal attributes later erased by policy	D04-UC-01, D04-UC-02
AgentVersionIdentity	Agent registry; Agent Control Plane	agent_version_id	Local foreign key to Agent; opaque creator reference to subject_id	organization_id	Immutable manifest and content digest after publication	Drafts may be deleted; published versions become immutable; retained while referenced by deployment or evidence, then tombstoned	D04-UC-01, D04-UC-03
WorkloadAttestation	Runtime identity registry; Runtime Identity Service	workload_identity_id	Opaque reference to runtime environment and attestation issuer	organization_id	Short-lived attestation must match approved workload and audience; never carries human authority	Issued at workload start; rotated automatically; expires quickly; metadata retained with security evidence	D04-UC-01, D04-UC-03
AuthorityDecision	Append-only evidence store; Authorization Service	decision_id	Opaque references to policy revision, context digest, agent version, deployment, connector, and downstream request	organization_id	Captures every conjunct and deny reason; immutable after write	Created for allow and deny; retained under audit policy; cryptographically sealed and eventually archived or deleted by retention rule	D04-UC-02, D04-UC-03
DelegationChain	Append-only evidence store; Audit Service	trace_id	Opaque references to run, capability decision, workload attestation, and external request	organization_id	Every external effect has a contiguous causal chain; gaps are explicit failures, never guessed links	Appended during execution; sealed at terminal state; retained for investigation; legal-hold aware deletion	D04-UC-03

The deletion rule mirrors authorization ownership: the Membership Service revokes membership, the Runtime Identity Service expires attestations, the Agent Control Plane retires versions, and the Audit Service retains decision facts. No owner waits for a copied global record to become authoritative.