For Azure administrators and developers, the useful question is how to turn that argument into enforceable boundaries. Microsoft Entra workload identity federation provides one concrete example: external workloads can exchange trusted identity tokens for Microsoft access tokens without maintaining a stored application secret in supported scenarios. But removing a secret does not remove the need to design authorization.
Identity belongs in the design, not the finishing touches
NIST’s Zero Trust Architecture, SP 800-207, supports the central principle. It rejects implicit trust based solely on network location or asset ownership and treats authentication and authorization as distinct functions before establishing access to an enterprise resource. Its focus includes users, devices, assets, services, and workflows—not simply the perimeter around them.
The architectural implication is straightforward: a diagram showing where an application runs should also explain what it can reach and why. A database connection is not merely a line between two boxes; it represents an access decision.
That does not mean identity replaces network security. NIST describes a resource-focused architecture, not permission to throw away other controls. The practical interpretation is that being on the right network cannot, by itself, settle whether a request deserves access.
The takeaway: identity design and infrastructure design should describe the same system, rather than become separate documents that disagree after deployment.
Federation removes a credential—not responsibility
Patil highlights federation as an alternative to maintaining separate credentials across systems, while warning that inconsistent groups, roles, and application policies can still make the combined environment difficult to govern.
NIST’s federation guidelines explain the underlying division of responsibility. An identity provider supplies an assertion; the relying party verifies it and establishes an authenticated session. Federation can avoid requiring a separate authenticator at each relying party, but the parties still need an explicit trust relationship.
There is also an important lifecycle wrinkle: an assertion’s expiration is not the same thing as the end of an application session. NIST explicitly separates the assertion’s validity window from sessions at the identity provider and relying party. Consequently, administrators should not assume that a short-lived assertion automatically delivers immediate access removal everywhere.
As an architectural recommendation, document authentication, authorization, and session termination separately. “We use federation” answers only part of the security questionnaire.
GitHub Actions makes the trade-off concrete
GitHub documents OpenID Connect as a way for Actions workflows to access cloud resources without storing long-lived cloud credentials as GitHub secrets. The cloud provider must first trust GitHub’s identity assertions, and the workflow must request and exchange a token.
Two details deserve particular attention:
- Token-request permission is not cloud-resource permission. GitHub’s
id-token: writesetting allows the workflow to obtain an OIDC token; it does not itself authorize changes to cloud resources. - Trust must be constrained. GitHub requires at least one cloud-side condition to prevent untrusted repositories from requesting access tokens. It also recommends environment protection rules where deployment environments are used.
The improvement is real but specific: the deployment path no longer needs that stored, long-lived cloud credential. It does not follow that an overprivileged deployment identity becomes safe.
What Azure teams should verify
Microsoft’s documentation separates configuring federation from granting access to target Azure resources. For an Entra app registration using the documented GitHub Actions setup, administrators identify the organization, repository, and an entity type such as an environment, branch, pull request, or tag. Those values must match the workflow configuration.
A useful review should therefore cover three independent checks:
- Trust configuration: confirm the external token’s issuer, subject, and audience match the federated credential. Microsoft specifies case-sensitive matching.
- Resource authorization: verify that the application has only the access intended for its deployment task.
- Actual token exchange: test the intended workflow, rather than treating successful creation of the federated credential as proof of correct configuration. Microsoft warns that incorrect subject information can be accepted during credential creation and become apparent only when exchange fails.
This also provides a troubleshooting distinction: failure to obtain an access token and failure to perform an operation against a resource belong to different parts of the design.
AI agents need an ending—but not an invented guarantee
Patil proposes tying an AI agent’s identity to the lifetime of its task so that abandoned access does not remain afterward. That is a lifecycle design recommendation, not evidence that all agent platforms automatically create and destroy identities this way.
A practical implementation review should ask:
- Who owns the agent’s identity and permissions?
- What event ends its need for access?
- What happens if the task crashes instead of finishing normally?
- How will the team verify that cleanup succeeded?
These are recommended acceptance questions, not claims about a particular product’s built-in behavior. The important distinction is between making credentials temporary and proving that unnecessary access has ended.
Build access removal into the architecture
The strongest lesson is not to replace one identity mechanism with another indiscriminately. It is to make access explainable from creation through retirement.
Federation addresses stored credentials; narrowly defined trust addresses who can obtain tokens; resource permissions address what those tokens enable. NIST, GitHub, and Microsoft document these as separate responsibilities. Treating them as interchangeable is precisely the architectural shortcut to avoid.