AI agent identity interview: why an agent’s identity should be a trust profile, not a login
An AI agent’s identity is usually a login. Shubham Anandani argues it should be a continuously updated trust profile — separating authenticity, credibility and uniqueness — and that point-in-time authorization is the core gap. In this AI agent identity interview, he works through the framework and is candid about where it is still conceptual.
About the Work
Shubham Anandani is an individual researcher rather than a company, so this section covers the work itself. His research sits in trust and identity for AI systems, and extends a human-focused framework to autonomous agents.
The specific proposal: an agent’s identity should not be a login but a continuously updated trust profile, separating three properties — authenticity (does observed behaviour match what the agent claims), credibility (verifiable provenance and authority), and uniqueness (a behavioural baseline). He is explicit that the agent extension is current thinking: conceptual, and not yet validated.
The published record includes the ACE-U framework (IEEE SoutheastCon 2026) and papers and a workshop at IEEE ISEC 2026, alongside talks at SecureWorld West and SecureWorld Healthcare 2026.
Executive Introduction
Shubham Anandani is a former Oracle Health Sciences engineer, and a Carnegie Mellon alumnus. He is writing here in a personal capacity: the views are his own, and he will not discuss his employer’s products — a boundary this interview respects throughout.
His research subject is trust and identity in AI systems. The argument is that an AI agent’s identity should not be a login but a continuously updated trust profile, and that frameworks built for human identity do not transfer cleanly to something that acts at machine speed. This AI agent identity interview tests that claim at the level of mechanism — what a trust profile contains, how continuous authorization is enforced, and why verified and inferred signals must never be blended.
He is candid about the status of the work: the agent extension is his current thinking, conceptual and not yet validated. Readers will come away with a clearer view of the authorization gap, of what authenticity, credibility and uniqueness each require, and of what it would take to turn a conceptual framework into something testable.
Identity as trust
Q1. In one line, why should an AI agent’s identity not be a login?
SA: A login shows that someone held a credential once, but an agent’s risk comes from what it does afterward, so its identity should be judged continuously, not granted once.
Q2. What is a “continuously updated trust profile” concretely — what does it contain, and what maintains it over time?
SA: It contains who the agent is (a unique ID, a named human owner, its model, version and tools), what it is allowed to do (scoped permissions, purpose, expiry), where its authority comes from (who built it and who attested to it), and its behavior history (actions, anomalies, incidents). Each item is labeled verified or inferred. An identity layer holds the attestations and policy, a signals layer updates behavior continuously from logs, and the owner re-attests on a schedule. Anything that isn’t refreshed expires.
The authorization gap
Q3. You describe point-in-time authorization as the core gap. What does continuous, scoped and revocable access actually require technically?
SA: It takes short-lived credentials issued per task with narrow scopes, and a policy check at each sensitive action, not only at session start. You also need real-time signals feeding that policy, a way to revoke mid-task that actually lands, and an audit trail linking each action to the agent, its owner and the authority it acted under.
Q4. What breaks first if you try to make agent access continuous — latency, policy complexity, or reliable revocation?
SA: My expectation is reliable revocation. The usual fixes for latency, such as caching and longer-lived tokens, delay how fast a revoke takes effect. Policy complexity grows as agents chain together. This is a design judgment, not something I’ve measured.
Authenticity, credibility, uniqueness
Q5. You separate authenticity, credibility and uniqueness. Walk us through what each means for an agent, with an example of an agent that fails one but passes the others.
SA: Authenticity: does the agent’s behavior match what it claims to do? Credibility: is there verifiable provenance and authority behind it? Uniqueness: can you tell this agent from any other, including a copy? As a hypothetical example, an agent with a valid owner and permissions (credible) and a distinct identity (unique) that says it only reads invoices but quietly exports data fails authenticity while passing the others.
Q6. How do you establish a behavioural baseline for uniqueness without that baseline itself becoming a privacy problem?
SA: Baseline the agent, not the people it serves. Collect metadata such as which tools it calls, which resources it touches, and when, not the content of what it handles. Keep it minimal, aggregate where you can, limit retention and access, and keep it separate from personal data. My healthcare talk made the same point: minimize sensitive data in identity models.
Verified versus inferred
Q7. Why must verified and inferred signals stay separate downstream, and what does “uncertainty attached” look like in a data model?
SA: Verified signals come from an authoritative source with proof. Inferred ones are a model’s estimate, with a different error rate and different accountability. Mixing them turns guesses into facts. In a data model, each signal carries its value, type (verified or inferred), source, timestamp, expiry and, for inferred ones, a confidence level and model version.
Q8. What goes wrong, concretely, when a downstream system treats an inferred signal as if it were verified?
SA: A concrete case: a model infers that an agent “is the finance reconciliation bot” and the system grants payment access on that label. A lookalike agent inherits the access. Errors also become sticky, hard to audit and hard to contest.
Misleading metrics
Q9. In your exploratory pilot study, high activity read as health to one evaluator and instability to another. What would context-aware agent metrics actually require?
SA: Metrics defined per task and per evaluator (operator, security, finance), with activity paired with outcomes such as errors, rollbacks, escalations and corrections. Show distributions instead of one count, explain why a metric moved, and treat spikes as a prompt to investigate. My pilot was small and exploratory, so this is a hypothesis to test, not a result.
Governance in practice
Q10. Explainability, privacy-first design, failing closed — which is hardest to implement for agents, and why?
SA: Explainability, in my view. Agent decisions come from multi-step, model-driven reasoning, so logs show what happened but not always why, and a reconstructed explanation can mislead. Failing closed is easy to define but costs availability. Privacy-first design pulls against the logging that explainability needs.
Putting the thesis to the test
Q11. You have said the framework is conceptual and not yet validated. What would it take to validate it — and what result would falsify it?
SA: Have expert raters score the dimensions and compare their scores with model estimates. Then run a simulation or red-team exercise with spoofed, cloned and over-permissioned agents, comparing the trust profile against a credential-plus-scope baseline. It would be falsified if it didn’t catch more misuse than that baseline at the same false-positive rate, if the dimensions turned out redundant, or if the signals were easy to game.
Q12. What is the strongest argument against treating agent identity as a trust profile rather than a credential, and how do you answer it?
SA: That credentials are simple, standard and auditable, while profiles are opaque, gameable and add privacy cost and attack surface. I agree with the risk, so the credential stays the anchor. The profile adds continuous context, keeps verified and inferred signals separate, routes risk to review, and never grants authority by itself. It also stays explainable and contestable, and it fails closed.
TechRecast Analysis (The Recast)
The Shift in Context
Identity systems were built for humans who authenticate once and act at human speed. Agents authenticate once and act continuously, at machine speed, across scopes nobody reviews in real time. That mismatch is where the authorization gap opens, and it is where this AI agent identity interview sits.
Why This Interview Matters
Most agent-security discussion is about what an agent can do; this is about how you know who is acting and whether they are still entitled to. It is a narrower and more tractable question, and it comes from someone publishing peer-reviewed work on it rather than selling a product.
Technology Perspective
The technical crux is two things: continuous authorization that is actually enforceable, and signal provenance that survives the trip downstream. If a downstream system cannot tell verified from inferred, it will treat a guess as a fact — and that is the failure mode that produces incidents no one can reconstruct.
Business and Market Perspective
The practical consequence for enterprises is that agent access needs to be scoped and revocable by default, not approved once at login. That is an architecture and policy problem before it is a product problem, and it is cheaper to design in than to retrofit.
Leadership Perspective
Anonymity of employer aside, the researcher’s position — engineering manager who publishes peer-reviewed identity work and speaks at security conferences — is the profile of a practitioner formalising what they see operationally. The relevant lens is whether the framework holds up under technical questioning, especially given it is not yet validated.
The Counterpoint
A fair sceptic would argue that a conceptual framework which is not yet validated is a hypothesis, not a result; that continuous authorization at machine speed is expensive and hard to enforce in practice; and that existing approaches — short-lived credentials, scoped tokens, policy engines — already cover much of what is proposed. On this view, the contribution is a useful vocabulary rather than a new mechanism. This is the strongest opposing case and deserves a direct answer.
What Comes Next
Watch three signals: whether “trust profile” gains traction as a term distinct from credential, whether signal-provenance metadata becomes a standard field in agent telemetry, and whether the framework moves from conceptual to validated with published evidence.
Industry Outlook
If the framework holds, agent identity becomes a continuous, evaluated property rather than a one-time grant, and downstream systems inherit provenance by default. If it does not, short-lived credentials and policy engines absorb the problem, and the trust-profile framing remains a research vocabulary.
Key Takeaways
1. An agent’s identity should be continuously evaluated, not granted once at login.
2. Point-in-time authorization is the core gap: approval at login can persist for hours while the agent acts at machine speed.
3. Authenticity, credibility and uniqueness are separable properties — an agent can pass one and fail the others.
4. Verified and inferred signals must stay distinct downstream, with uncertainty carried alongside them.
5. Activity volume is a misleading metric; the same signal reads as health or instability depending on context.
6. The strongest counter-argument is that the framework is unvalidated, and existing short-lived credentials may already cover much of it.