💡 OIDC Attribute-Based Access Control Standard for Org Workflows

[github-actions[bot]]

Summary

Define an org-wide standard for using GitHub Actions OIDC custom property claims and immutable subject claims to create attribute-based access control (ABAC) policies across all org workflows. Each repo's OIDC tokens would carry custom properties (e.g., repo-type=infra, team=platform) that cloud provider trust policies use for fine-grained credential scoping.

Market Signal

GitHub Actions OIDC custom property claims reached GA in April 2026. Immutable OIDC subject claims are rolling out for all new repos after June 18, 2026 (changelog). These primitives enable per-repo ABAC policies without modifying individual workflows — but no org-level adoption pattern exists. GitHub's 2026 Security Roadmap also includes scoped secrets and a native egress firewall, all pointing toward a zero-trust CI model.

User Signal

The "Comment and Control" vulnerability class (CVSS 9.4, April 2026) demonstrated that over-privileged credentials in agent CI jobs are the primary prize for attackers. The org has heavy agent workflow usage (claude-code, agent-shield, compliance-audit) that all receive broad credentials. Issue #206 (Monitor and Optimize Token Usage) reflects awareness of credential governance gaps. Multiple compliance-audit findings show the need for tighter security controls.

Technical Opportunity

The org already defines repo settings centrally via apply-repo-settings.sh and enforces standards via compliance-audit.sh. Adding custom property definitions to the repo settings script and OIDC claim validation to the compliance audit is a natural extension of existing patterns. ci-standards.md would gain an OIDC section defining:

• Required custom properties per repo type (e.g., repo-type, team, sensitivity)
• Trust policy templates for major cloud providers (AWS, GCP)
• Compliance audit checks for OIDC claim configuration

Assessment

Dimension	Score	Rationale
Feasibility	high	OIDC custom properties are GA — this is standards + compliance audit changes, no new infrastructure
Impact	high	Org-wide credential security improvement, reduces blast radius of any agent compromise
Urgency	high	Immutable subject claims rolling out June 2026 — ideal adoption window. CVSS 9.4 attacks proven in the wild

Adversarial Review

Strongest objection: GitHub ships the primitives natively — this is just documenting what they already provide. Standards nobody reads have zero impact.

Rebuttal: GitHub ships primitives but does NOT prescribe how multi-repo orgs should use them. The gap is "which properties to define, which trust policies to configure, how to enforce adoption." This org's compliance audit runs daily — adding OIDC checks means the standard gets enforced, not ignored. And with CVSS 9.4 credential theft attacks proven in the wild, narrowing token scope is the highest-ROI security investment available right now.

Suggested Next Step

Draft an OIDC ABAC section for ci-standards.md defining required custom properties per repo type, recommended trust policy templates for AWS/GCP, and add OIDC claim verification to compliance-audit.sh.

[github-actions[bot]]

Weekly Update

What Changed

Expanded OIDC support for Dependabot and code scanning (May 20, 2026): GitHub expanded OIDC support to Dependabot and code scanning for private registries at the organization level, adding Cloudsmith and Google Artifact Registry. This makes OIDC the standard authentication mechanism across more GitHub-native workflows, strengthening the case for an org-wide OIDC standard.

Attribute conditions recognized as critical security control: Industry guidance now identifies the attribute-condition (CEL expression filtering which OIDC tokens are accepted) as the single most important security control for workload identity federation — preventing any GitHub repository from assuming your organization's cloud identity.

Environment-based access control recommended for production: Best practices now recommend using GitHub Environments with required reviewers for production deployments, rather than branch-based subjects.

Updated Assessment

Dimension	Previous	Current	Delta
Feasibility	med	high	↑ (expanded GitHub OIDC support reduces implementation effort)
Impact	high	high	→
Urgency	med	high	↑ (OIDC is now available for Dependabot + code scanning)

Recommendation

Advance — GitHub's expanded OIDC support makes this easier to implement and covers more use cases than when the idea was originally proposed. Start with attribute condition policies for existing workflows.

[github-actions[bot]]

Weekly Update — 2026-05-29

What Changed

GitHub OIDC custom properties for repository tokens reached general availability (March 12, 2026). This is the core enablement signal for this proposal:

1. Feature: Organization and enterprise admins can now select custom properties to include in OIDC tokens. Every repository with a property value set automatically includes it in tokens, prefixed with repo_property_.
2. Configuration: New settings UI at repository, organization, and enterprise levels. Custom properties can also be added via API.
3. ABAC use cases now confirmed: The feature enables attribute-based access control in AWS, Azure, GCP, and other cloud providers — driven by repository metadata (e.g., business_unit, data_classification, environment_tier) rather than hard-coded allow lists.
4. Key benefits documented by GitHub: Centralized governance (metadata flows automatically into cloud policies), reduced drift (policies bind to repository attributes), streamlined onboarding (new repos inherit correct access automatically), cross-cloud consistency.

Additionally, the GitHub Actions 2026 security roadmap announced that OIDC tokens now include check_run_id claims, enabling even more granular trust policies.

Updated Assessment

Dimension	Previous	Current	Delta
Feasibility	med	high	↑
Impact	high	high	→
Urgency	med	high	↑

Recommendation

Advance. The feature this proposal depends on is now GA with full API and UI support. Feasibility increased from medium to high — the org can implement this today without waiting for any preview features. Recommend defining the standard custom properties for petry-projects repos (environment_tier, agent_access_level, data_classification) and creating a workflow template that demonstrates OIDC ABAC with at least one cloud provider.