I love Lovable. Cliche I know, but seriously it's my favorite app builder and I love the Plan vs Build features which allow me to hash out an idea quickly and see it come to life
You know the problem. Now build the fix.
You've spent years close to a broken industry or process. You know exactly what would fix it. But you’ve never had the time or resources to make it happen.
With Lovable, your expertise is all you need. Describe the solution to your problem — a website, a dashboard, an internal tool — and get professional-grade software back. You make every call on how it works, because you're the one who knows what it needs to do.
Start today and take $5 off your first month.
Discount of $5 applies to first month of any paid plan. You need to sign up via this webpage in order to claim the discount. The discount applies to new and returning users without an active paid plan. Terms apply.
-THE WIRE THIS WEEK IN IDENTITY
N°01 · BREACH
A state actor ran an AI agent through ConnectWise's app identities
Microsoft attributed the ConnectWise Cloud Backup compromise to Storm-0940, a China-state aligned group, and said the group used an agentic AI penetration testing framework called ARTEX to run the campaign. After the unauthorized access at ConnectWise, which the company first disclosed on October 16, the group used ARTEX to attempt sign-ins to more than 2,250 downstream tenants. Microsoft reports that in multiple cases the time from first targeting to privileged access was under three hours.
For identity teams, the important detail is how they stayed in. Storm-0940 added its own credentials to existing OAuth applications, so the backdoor lived on an application identity that already had access to Microsoft 365. Microsoft's guidance is to review service principal sign-ins and investigate any unexpected application credential or privilege changes. That review only works if each of those applications has an owner who would notice a credential they did not add.
N°02 · STANDARD
NIST proposed ten design tenets for agent identity
NIST published ten proposed design tenets for agent identity, authentication and authorization on October 27, drawn from the public comments on the NCCoE's agent identity and authorization project. The list starts with distinct agent identities and runs through linking and delegation, zero standing privilege, short-lived and revocable authorization, human-in-the-loop triggers, separating policy from the agent's reasoning, deterministic access decisions, continuous monitoring and immutable evidence.
Tenet two is the one that maps to this issue. It calls for every agent to be cryptographically linked to the person or organization that initiated its task, so its actions can always be attributed to a responsible party. That is an ownership chain written as an architecture requirement. It is published as a proposed starting set on NIST's blog, so read it as the direction NIST is heading and a useful checklist for your own program.
Hey {{first_name|Jedi}},
For twenty issues we built the program. Find the agents, assign the owners, migrate the credentials, stand up the audit trail, and certify on events instead of porting the employee review cycle onto agents. If you followed along, you have a program on paper and some of it running underneath.
Now you have to run it. This issue covers the five places an agent identity program starts coming apart once the build team moves on, and then the one fix that makes the other four manageable, with the steps to put it in place.
Five places operating breaks
The inventory goes stale. A discovery scan is a photograph. Agents get created, re-scoped and abandoned every week, and the inventory only stays true if someone keeps it true. The Cloud Security Alliance's May 2026 whitepaper reports that 47% of non-human identities go unchanged for over a year and that 51% of organizations have no clear ownership of AI identities. That is what discovery looks like after the maintenance stops.
Agents get provisioned around you. A platform team spins up three agents through a cloud console or a SaaS admin panel, and none of them pass through your intake process. Your policy covers the agents you know about.
Scope creeps. An agent built to read tickets gets write access to unblock one workflow, and the grant never comes back. Agents pick up permissions the same way service accounts did, only faster, because the person asking is usually trying to ship something by Friday.
Owners drift. You named a Principal Owner for every agent. Then people changed teams, left the company, or inherited six agents in a reorg without being told. The name on the record and the person who understands what the agent does slowly come apart, and the gap stays invisible until an incident forces the question.
The audit trail floods. An agent generates orders of magnitude more activity than an employee. When every event lands in a queue a human is supposed to review, the queue stops getting read. That one gets its own issue next week, when we take agent identity into the SOC.
Fix ownership first
Look at where each of those problems ends up. A stale inventory entry needs someone to confirm the agent still exists. A shadow agent needs someone to claim it or kill it. A creeping grant needs someone with the authority to say the write access is no longer needed. An alert needs someone to call. Every control you built routes to an owner, so when the owner field is wrong, every control routes to a dead end. If you can make one operating loop real this quarter, make it ownership. Here is how to build it.
Every control you built routes to an owner. When the owner is wrong, the control routes nowhere.
Bind the owner to the HR record
Most agent inventories store the owner as a text field or an email address, and that field never changes when the person does. Store the owner as a reference to the person's identity in your HR system or IdP instead, so the agent record inherits the person's status. When an owner is terminated or transferred, the agent knows the same day, because the joiner, mover and leaver events you already process for humans now carry the agents attached to those humans.
Give every agent a team, a primary and a backup
One named human is a single point of failure. Assign a primary owner, a backup owner from the same team, and the owning team itself. When the primary leaves, the backup takes over automatically and the team lead gets a notice. When both are gone, the agent lands with the team lead, who has a fixed window to reassign it or retire it. Pick the window that fits your organization. Fourteen days is a reasonable place to start.
Restrict orphans on a timer
An agent without a valid owner should lose privilege automatically. On day one, flag it. When the reassignment window closes, drop it to read-only or suspend its credentials. If it stays unclaimed past a second window, retire it. Expect pushback on this rule until the first time it catches a forgotten agent holding production write access. Write it down, get the platform teams to agree to it before you enforce it, and then enforce it.
Confirm ownership when something changes
Resist the urge to add agents to the annual ownership attestation you run for service accounts. Ask the owner to confirm purpose and scope at the moments that carry information: a new permission grant, a new data source, a new integration, or an owner handoff. A confirmation tied to a real change tells you something about the agent. A confirmation on a calendar mostly tells you who is willing to click approve.
Run one query this week
You can start before any of that is built. Export your agent inventory with its owner field and join it against your list of active employees. Every agent whose owner is terminated, transferred or unresolvable goes on your orphan list. Count it, put the number in front of whoever runs your platform teams, and track it every week. Two numbers tell you whether the ownership loop is working: the share of agents with a valid, active owner, and the number of days an orphan sits before someone claims it.
The Last Word
Building a program and running one are different jobs. The build gave you an inventory, owners, an audit trail and a certification model. Running it means keeping all four true while the organization changes underneath them, and ownership is the piece that holds up the other three. The EU's Digital Omnibus on AI moved the high-risk obligations for stand-alone Annex III systems to December 2, 2027, which buys some time. Spend it on the ownership loop, because the first question anyone will ask about an agent, whether it's an auditor or your incident commander, is who owns it.
So run the query. How many of your agents have an owner who still works at your company? Hit reply and tell me. I read every one.
See ya next week.
Be good to each other, be kind to each other, love each other


