There are hints of this in a system Amazon used for service to service authentication and encryption. In the initial implementation, a daemon ran on the system syncing data specifically for that host from a central keystone. Applications could then use that daemon to sign content, encrypt outbound traffic, and authenticate clients (at the API level, iirc) while the application never needed to know anything about the keys or algorithms used.
Java folks being Java folks, however, decided that having this external process was a faulty design, for some reason and decided to rewrite it in Java and have it run in the same JVM as the app (with some huge performance implications, at least at first).
Like most tools at Amazon, this extended back to developer desktops, so even development keys could be generated, and autorotated without developers needing to know about them. Group based access ensured they were sent to hosts when new employees entered a group and were removed when they left the group.
This sounds vaguely similar to Managed Service Identities in azure as well. Apps can ask a well-known IP that maps to a local service on the VM host for an oauth token to any azure service, and then it gets back a token with an identity tied to the VM/webapp/function app without needing to do any of the oauth flow itself. I don't think it quite gets to the point of signing content or encrypting connections, though I might have just never seen it.
A lot of internal Amazon ideas eventually make their way to the public as AWS offerings, typically with limitations due to them needing to be public offerings without dev teams that can sit in a room at a moments notice and decide on any necessary changes. Typically that means the AWS offering is lacking features compared to the internal version, but eventually teams are encouraged to migrate (I’ve been away from Amazon for about 4 years, but that’s still the impression I get). Lambda, DynamoDB, Code Deploy, Autoscaling Groups, ALB/NLBs (load balancer tied to an ASG), Cloud Watch, SQS, etc. all had internal equivalents which often were better (imho) than the AWS offering. Some were hosted (by another team), some needed to be managed by each team (which made the move to AWS more compelling).