“Automation never took people out of work. It just took their names off it” — Nadina D. Lisbon
Hello Sip Savants! 👋🏾
According to Okta's August 24 announcement, most AI agents use static API keys and one-off grants, like guests who never fill out a visitor log. They operate in company systems "as anonymous traffic with no owner, no policy, and no audit trail" [1]. That same day, Okta made Agent SSO generally available. With this change, Okta allows agents to have their own identities instead of being recognized as someone else's shadow. This design is a real break from how automation has worked. If an agent has its own name, so does the work it touches. These three items are worth a few minutes this week.
3 Tech Bites
🪪 Agents get a login of their own
Okta released Agent SSO on August 24, bringing Cross App Access into its identity product, which is used by more than 20,000 customers, at no extra cost [1]. The integration gives an agent its own directory account alongside the employees, and issues a short-lived token each time it connects to an application, in place of a stored credential.
📋 A name at creation, not after the fact
According to the Cloud Security Alliance blog, published on August 20, every agent should have its own identity, with a named owner recorded the day that identity is created, rather than assigned later when an explanation is needed [2]. The maturity model also offers a better metric to report than inventory coverage: how long it takes to revoke a credential. The statement “nobody offboards an agent” resonated with me [2].
🚦 What is actually slowing agents down
Announcing on August 24, Google Cloud stated that 79 percent of tech leaders name security, governance, or operations as their biggest challenge when scaling inference [3]. Okta’s research describes the same gap: of the organizations surveyed, only 34% apply the same security controls to agents that they apply to people [1]. This looks more like a lack of a decision than a lack of available tools.
5-Minute Strategy
🧠 Check What’s Running as You
Most early AI pilots got built using the sponsoring executive’s own login, because that was the fastest way to get access. It may be worth five minutes to see what that left behind on your account.
Hop over to the work account you use most and check the security or privacy settings. Or check your identity provider’s control panel, if that is where you log in every day.
Click on the section that lists connected apps, third-party access, or integrations.
Read it carefully and don’t be in a rush. It could include pilots, scripts, or internal tools you consented to one time and haven’t thought about since.
Check the first entry that you don’t recognize. Find out what it can access and when access was granted.
Write that information on a Post-it and put it somewhere you will see it daily.
Now you have your first entry in an agent inventory, done directly by you, concerning your account.
1 Big Idea
💡 Getting the Byline Back
Professionals who write for a living can describe the uncomfortable feeling of work that goes out under someone else’s name, or under no name at all. A quieter version of that has been happening inside companies running early AI agents. The agent does the work. It reads an email, sends a request to the database, creates a support call. But the login it used belonged to a person, so the system records that person as having performed the task.
This is not a case of someone being careless. It is how the plumbing got built, one system and one API key at a time, back when an agent touching a system was still an experiment. Okta describes the result in straightforward language: agents operating as “anonymous traffic with no owner, no policy, and no audit trail” [1]. Anonymous traffic is a rather odd way to describe something that reads your company’s emails, and yet that is what a borrowed login creates. There is no name recorded, so nobody in particular to ask.
What changed this month is small and specific. Agent SSO assigns an agent a unique identity in the same directory as the people it works alongside, and issues short-lived tokens in place of a borrowed password [1]. The Cloud Security Alliance goes a step further and suggests recording a named owner the day an agent is created, so accountability exists in advance rather than getting reconstructed after the fact [2]. That is basically a byline. It is a modest change as engineering goes. It is also the infrastructure for credit, trust, and corrections.
The practical case for it is calm rather than dramatic. In one survey by Okta, 58% of executives reported an AI-related security incident or near miss in the last 12 months, and Okta finalized its acquisition of Permiso Security on August 26 to manage human, non-human, and agentic identities together rather than in separate streams [4]. These do not warrant concern. They mean that in the cases where a review is needed, there is a name to look up rather than a shared password and a shrug.
A byline does not take anything away from the person who used to do the work. A byline adds value. When the record shows who did what, credit and correction both go to the right person, and people get to spend their attention on the parts of the work that genuinely need them. That seems worth wanting, for the agents and for everyone working alongside them.
Tell me about what turned up on your own access list, or what surprised you. I read every response.
P.S. If a peer is still bracing for cuts when the data points the other way, share this newsletter and help brew up stronger customer relationships.
P.P.S. If you found these AI insights valuable, a contribution to the Brew Pot helps keep the future of work brewing.
Resources
[1] Okta brings first-class identity to AI agents with Agent SSO
[2] Governing AI Agent Identities: An Identity Maturity Model for AI Agents
[3] Empowering autonomous agents with advanced security governance
[4] Okta acquires Permiso Security
Sip smarter, every Tuesday. (Refills are always free!)
Cheers,
Nadina
Host of TechSips with Nadina | Chief Strategy Architect ☕️🍵


