How to know more about the Agents in your Organization
Organizations are spinning up AI agents every day.
Agents that read customer data. Agents that write to databases. Agents that send emails, execute transactions, file records, and make decisions that affect real people. Dozens of them. Sometimes hundreds.
And in most organizations, nobody has a complete answer to three basic questions:
- Where are they all?
- What are they doing?
- Who built them?
It is an identity problem that leads to the broader AI governance problem. And it has a straightforward solution that any organization can now implement.
How agents get deployed today.
It usually starts with someone in an organization who spins up an agent to handle a repetitive workflow. It works. Another team does the same. Then another. Agents get cloned, modified, and repurposed. They get handed off between teams. The person who built the original is no longer on the project. The agent keeps running.
Meanwhile, somewhere in IT, someone is trying to maintain an inventory of the AI systems the organization runs. They are doing it in a spreadsheet. It is already out of date.
This is the current state of AI deployment in most organizations, moving at any real pace. The agents proliferate faster than governance can catch up.
The reason is simple. Spinning up an agent requires almost no formal process. An API key, a prompt, a connection to a few systems, and the agent is running. There is no moment of establishment. No record of intent. No declaration of who is responsible. The agent simply exists and begins acting.
Access control is not identity.
When organizations do think about agent governance, the conversation usually lands on access control. What systems can this agent reach? What permissions does it have? That is a useful question. It is not the same question as: who is this agent, what is it for, and who is accountable for what it does?
An API key proves that a request is coming from something that possesses a particular secret. That is all. Two agents built by different teams for completely different purposes can share the same key. The key cannot tell them apart. It cannot tell you who built them, what they were intended to do, or who to call when something goes wrong.
A service account governs access. It does not answer any of the questions that accountability requires. When an agent causes a problem, the question is not just whether it had permission to reach the system. The question is who authorized it, what it was supposed to be doing, and whether its behavior was consistent with what anyone actually intended when they deployed it.
The industry has invested heavily in what agents can reach. Almost nothing is known about what agents are.
Three questions every organization should be able to answer.
Where are your agents? Not the ones you know about. All of them. The ones your team built, the ones other teams built, the ones that got modified and redeployed without a formal record, the ones that are still running because nobody turned them off.
What are they doing? Not in general terms. Specifically. What actions are they authorized to take? What systems are they touching? What is the scope of their authority, and who declared that scope explicitly rather than letting it be implied by whatever they happen to have access to? These questions also apply to authority laundering in multi-agent systems.
Who built them? More precisely, who is accountable for them right now, today, if something goes wrong? Not who created the original version. Who owns the governance of this agent at this moment, and can that be verified without digging through Slack history or tracking down someone who may have left the company?
Most organizations cannot answer all three questions for all of their agents. Some cannot answer any of them with confidence.
What Agent Birth Certificates do.
This is the problem Nomotic’s Agent Birth Certificates were built to solve.
Before a governed agent takes any action, it receives a signed identity document. Not an API key. Not an internal ID. A cryptographically signed artifact that records, at the moment of creation, everything those three questions require: who owns it, what it is authorized to do, what behavioral category it belongs to, what governance configuration it is operating under, and when all of that was formally established.
nomotic birth --name customer-records-agent \
--archetype customer-experience \
--org acme-corp \
--owner operations@acme-corp.comWhat comes back is a governance artifact.
Certificate issued: nmc-8c4f2a1e
Agent: customer-records-agent
Owner: operations@acme-corp.com
Archetype: customer-experience
Zone: production
Trust score: 0.500 (baseline)
Status: ACTIVE
Gov hash: sha256:a3f9...
Signed: Ed25519From this moment on, the agent has verified identity. Every action it takes carries that identity into governance evaluation. The owner fields the accountable human. The scope field declares what the agent is authorized to do, not inferred from access, but explicitly stated and signed. The governance hash means that if the configuration the agent is operating under changes without a formal renewal, the discrepancy is detectable.
When the agent is decommissioned, one command revokes it, seals the audit trail, and preserves the complete history. The record of what this agent was, what it was authorized to do, and everything it did is preserved and verifiable.
Where this is heading.
Right now, most organizations are operating on trust and spreadsheets. They trust that their teams are deploying agents responsibly. They maintain perpetually incomplete inventories. And when something goes wrong, they reconstruct accountability after the fact by searching logs and interviewing people.
That approach works until it doesn’t. As agents become more capable and their actions more consequential, the questions will get harder and the stakes will get higher. Regulators are already asking about AI governance. Legal teams are already thinking about accountability chains. Boards are starting to ask questions for which nobody has a clear answer.
The organizations that will navigate that environment well are the ones that built identity infrastructure before they needed it. Not in response to a problem. Before one arrived.
The questions of where your agents are, what they do, and who built them should have verifiable answers. Not a spreadsheet. Not a Slack thread. A cryptographically signed document that exists from the moment each agent was created.
That is what Agent Birth Certificates are for. And it is a simpler problem to solve than most people think.
If you find this content valuable, please share it with your network.
Follow me for daily insights.
Book me to speak at your next event.
Chris Hood is an AI strategist and author of the #1 Amazon Best Seller Infailible and Customer Transformation, and has been recognized as one of the Top 30 Global Gurus for Customer Experience. His latest book, Unmapping Customer Journeys, will be published in 2026.