Who signed for the agent?

AI output is only as good as what sits underneath it, and a lot of companies are finding that out the hard way.

In September, Collibra published a Harris Poll survey of 306 U.S. data and AI leaders at director level and above. 72% agreed that when their AI initiatives fall short, the root cause almost always traces back to an unaligned or poor data foundation. Collibra sells data governance, so read it with that in mind. The pattern still matches what we see in the field.

We read the first number as a sequencing problem. Failures come more often from what the AI is built on than from the AI itself. Take internal support automation. Good data there means more than clean tickets. It means knowing who owns what, and having the real handling rules written down and signed off by someone with the authority to sign. Skip that and the automation misroutes requests and wastes your employees' time at machine speed.

The third number is the one we would question. Accountability that lives in an org chart is easy to report in a survey. Accountability you can prove for a specific action, taken by a specific agent, on behalf of a specific person, is a different matter. That proof depends on identity, and identity is the part of the agent foundation most teams have not built yet.

NIST's ten tenets

On October 27, NIST's Cybersecurity Insights blog published ten design tenets for agent identity management systems, drawn from public comments on an NCCoE agent identity project. If you build agents or buy them, this is the list to validate against. Here is each tenet with the question we would ask of any deployment or vendor.

• 1. Distinct agent identity. Every agent gets its own verifiable identity, separate from human users and service accounts, with its own lifecycle. Ask: can you list every agent in production by name, or are some running under a shared service account?
• 2. Linked to a human, and only narrowing. Every action traces back to the person or entity who started the task. When an agent hands work to a sub-agent, the authority can shrink but never grow. Ask: for any action in the logs, can you name who asked for it?
• 3. Zero standing privilege. An idle agent holds nothing. A working agent holds only what the current task needs. Ask: what can this agent reach right now, while it is doing nothing?
• 4. Short-lived, revocable access. Access is granted just in time, expires on its own, and can be pulled mid-task. Long-lived tokens and static secrets are out. Ask: how many API keys in agent configs have no expiry date?
• 5. Human review where risk calls for it. Risky actions route to a person with enough context to judge them. NIST names consent fatigue directly: if everything needs approval, approvals turn into rubber stamps. Ask: what share of approval requests get rejected? Close to zero usually means the reviewers stopped reading.
• 6. Mandates. What was approved gets recorded as a signed scope of work, and downstream systems can check the agent against it. Ask: where is the written record of what this agent was told it could do?
• 7. Policy kept apart from reasoning. The part of the system that decides what the agent tries to do is separate from the part that decides what it may do. Untrusted input reaching the model cannot change credentials or widen permissions. In NIST's words, guardrails alone are insufficient. Ask: if a prompt injection fully succeeds, what can the agent still not do?
• 8. Deterministic access decisions. A model's output can inform an access decision. It does not make one. Ask: does any permission check in your stack depend on an LLM saying yes?
• 9. Continuous monitoring. Agents act at machine speed, so monitoring needs agent-specific baselines and thresholds, especially for long-running agents with many tools. Ask: would you notice if an agent's tool calls tripled overnight?
• 10. Evidence the agent can't change. An append-only, tamper-evident record of what the agent was asked to do and what it actually did, logged outside the agent's reach. Ask: could a compromised agent edit its own audit trail?

What NIST admits up front

The authors are candid that today's standards and tooling cannot deliver all ten tenets across every deployment model. They present the list as a starting point for assessing capabilities and building a roadmap, and they say no single tenet is enough on its own. Apply each one in proportion to the risk of what the agent is doing and what it can touch.

That is useful guidance for buyers. A vendor claiming full coverage of all ten today deserves follow-up questions. A vendor who shows you exactly which tenets they meet today and when the rest are coming is giving you a straight answer.

Where to start

Most teams can close the biggest gaps without new products. Inventory every agent and move each one off shared service accounts onto its own identity. Replace static keys in agent configs with short-lived, scoped credentials. Ship agent logs somewhere the agent cannot write to. Then put a deterministic policy check between the model and anything that changes data or spends money.

Those four moves cover the tenets auditors will ask about first, and they make the rest of the list far easier to reach.

How we approach it at Aegis

We start every engagement with the foundation, not the build. That means the data and who owns it, and now the identity layer under every agent you run or plan to run. We map your agents against NIST's ten tenets, show you where the gaps carry real risk, and sequence the fixes so your teams keep shipping.

An agent that can't tell you who sent it shouldn't be holding the keys.