Your AI Agent Has an ID. Can It Keep One When Its Keys Change?

CYBERSECURITY · BLOG 26 | 14 October 2026

An AI agent in a software pipeline is more than a clever assistant. Depending on how it is built, it may authenticate to a code repository, read project data, run tools and propose or perform actions. The security question is no longer only “Is the model safe?” It is also: which non-human identity did the work, who delegated authority to it, and can that identity be limited, audited and replaced without losing control?

That question has a timely Singapore and post-quantum dimension. Agent security is moving from general principles toward implementation examples, while organisations are being asked to prepare for a future migration of public-key cryptography. The practical opportunity is to design agent identities that remain accountable even as credentials and cryptographic algorithms evolve.

In brief: Give each agent a named owner, a distinct workload identity, task-limited access, traceable actions, a tested revocation path and a documented route for changing cryptographic components. Do not interpret “quantum-ready” as a reason to replace every credential immediately.

Download the companion slides: AI-agent identity and crypto-agility presentation (PDF)

What changed: agent identity is becoming an implementation problem

On 29 September 2026, the U.S. National Cybersecurity Center of Excellence (NCCoE) said its first implementation use case for software and AI-agent identity would be inside the software-development lifecycle. The planned example is intended to demonstrate how agents can be identified, authenticated and authorised in DevSecOps. The announcement followed more than 600 comments on NIST’s concept paper. This is an implementation project—not a final standard or a claim that every organisation should use one particular identity product. (NIST NCCoE, 29 September 2026)

The underlying questions are concrete. NIST’s February 2026 concept paper asks how agent identities should be represented; how authentication keys are issued, updated and revoked; how access should be delegated from a person; and how records can connect an agent’s action back to that authorisation. The paper is explicitly a concept paper seeking feedback, so treat it as a useful map of open engineering questions—not binding guidance. (NIST NCCoE concept paper, February 2026)

Singapore’s Cyber Security Agency (CSA) has also published agent-specific guidance. Its addendum says system owners should map agentic workflows to identify where risks may arise and consider controls across the development lifecycle; its examples include coding assistants, automated onboarding and fraud detection. (CSA, 17 June 2026) Separately, a Singapore Government–Google sandbox explored computer-use agents. In its May 2026 summary, IMDA notes that much digital infrastructure was designed around human users and that identity, authentication, permission and access-control foundations may need to evolve for agent-driven interaction. The sandbox was exploratory; it is not evidence that every enterprise has deployed such agents in production. (IMDA, 20 May 2026)

Why quantum-safe migration belongs in the same design conversation

An agent’s “identity” may touch several layers: an account or workload principal, an authorisation token, a TLS connection, a certificate, a signing key, a code-signing service or an identity provider. The exact cryptography depends on the design. An opaque bearer token, a signed token and a certificate-based workload identity do not have identical properties; they should not be treated as one interchangeable thing.

The useful connection is crypto agility. NIST’s final CSWP 39upd1, updated on 29 June 2026, describes crypto agility as the ability to adapt or replace cryptographic algorithms across protocols, applications, software, hardware, firmware and infrastructure while preserving security and ongoing operations. (NIST CSWP 39upd1)

That matters for agent identities because an algorithm or certificate transition must not silently change who an agent represents, whose authority it carries or how its actions are audited. This is an architectural inference, not a reported production failure: if an agent’s permission model, human delegation record and signing-key implementation are tightly coupled, a future credential or algorithm change could turn a planned migration into a rushed application rewrite—or break the audit trail.

Singapore’s updated Quantum-Safe Migration Handbook and Quantum Readiness Index (QRI), released by CSA, GovTech and IMDA on 16 July 2026, describe migration as a complex, multi-year effort and state that the quantum threat timeline remains uncertain. The QRI is a self-assessment across five domains that helps organisations prioritise readiness work. These resources support preparation, not panic. (CSA, 16 July 2026) NIST says its three first post-quantum standards are ready to implement, but the right path for a specific agent system still depends on the system’s actual cryptographic dependencies, vendor support, interoperability and applicable requirements. (NIST Post-Quantum Cryptography)

Important distinction: crypto agility is not the same as installing a new algorithm everywhere today. Nor is “PQC-ready” a substitute for strong agent identity and access control. It means knowing which cryptographic component does what, separating that component from business identity and authorisation where feasible, and testing change safely.

The SCOPE model for accountable, crypto-agile agents

Use this five-part design check before an agent receives access to code, cloud resources, customer records or operational workflows:

S — Sponsor every agent

Assign a named business owner and technical owner. Record what the agent is for, which human or approved workflow can invoke it, which systems it can reach and who can approve changes to its permissions. A model name is not an accountable owner.

C — Constrain each task

Use a distinct workload identity for each agent or tightly bounded service—not a shared administrator account. Grant only the tools, data and actions needed for its purpose. Keep high-impact actions such as production deployment, privilege changes or bulk data export behind a separate approval step where the risk warrants it. Do not let text from a prompt, webpage, issue or document expand the agent’s permissions.

O — Observe the authority chain

Log enough context to reconstruct the action: initiating user or workflow, agent identity, policy decision, tool or API, target resource, credential identifier, time and outcome. Avoid placing secrets or unnecessary sensitive prompt content in ordinary logs. The goal is to answer “which identity did what, under whose authority?” without creating a second data-leak channel.

P — Pause and revoke

Document how to stop an agent run and revoke its grants or credentials without disabling unrelated workloads. Prefer credentials with a bounded lifetime and rotation path where the platform supports them. Test revocation and recovery; an untested “kill switch” is only a design assumption.

E — Evolve the cryptography

Map the cryptographic dependencies that actually protect the agent’s connections and assertions: for example, TLS, certificate chains, signing services, key stores, code-signing and relevant identity-provider or vendor integrations. Record the algorithm, owner, renewal or rotation process, dependency and replacement path—not secret key material. Test supported algorithm changes in a non-production environment and confirm interoperability before rollout.

The result should be an identity envelope that can be pictured as: human or workflow sponsor → named agent principal → scoped task credential → approved tool/action → attributable audit record, with cryptographic mechanisms replaceable beneath that chain.

SCOPE infographic: a quick visual reference

The infographic below turns the article’s framework into a web-native, mobile-readable visual; the linked PDF is the original NotebookLM export. It is an original illustration based on this article and its cited sources, not a documentary incident image.

A practical 30-day sequence

Guidance vs. scenario: NIST and CSA provide governance and implementation guidance; the key-rotation example in this article is hypothetical, not a reported outage. PQC migration is a planned, multi-year transition—not a reason to replace every credential today.

Download the SCOPE infographic (PDF)

Text alternative: Sponsor—name a human owner. Constrain—use task-limited privileges. Observe—log the full authority chain. Pause—test stopping and revoking access. Evolve—inventory cryptographic dependencies and test a migration path. The suggested 30-day sequence is days 1–3 for inventory and owners, days 4–14 for task scopes and approvals, and days 15–30 for connected logging, revocation tests and crypto recovery evaluation.

A clearly hypothetical scenario: the bot that survives the key rotation

Imagine a development team gives an AI code-review agent a shared CI service credential that can both read repositories and trigger deployment. A future prompt-injection attempt or misconfigured workflow causes an unexpected tool call. The team rotates a signing key during a wider crypto upgrade, but its logs still show only the shared CI account. It can rotate the key and still be unable to answer which agent instance acted, which human authorised that run or whether the replacement credential has the same excess privileges.

This is a hypothetical design scenario, not a reported incident. The control is to separate the questions: identity says which workload acted; delegated authorisation says what it may do and for whom; cryptography proves or protects the relevant exchange; logging preserves the chain. They should work together, but one layer should not stand in for the others.

A prioritised 30-day plan—and who should own it

When	Action	Accountable owner
First 72 hours	Identify agents that can change production code, cloud configuration, customer records or other high-impact data. For each, record its sponsor, principal, permissions and credential type. Add a human checkpoint to a high-impact action if its authority or audit trail is unclear.	CIO/CTO sponsor with IAM and application-security leads
Days 4–10	Replace shared or ownerless agent credentials with distinct workload identities; document delegated authority; remove unused tools and broad grants. Ensure each identity has a support owner and decommissioning path.	IAM / cloud-platform owner
Days 11–20	Connect logs across the initiating user or workflow, agent, tool call, target resource and result. Define approval gates for privileged or irreversible actions. Exercise pause, credential revocation and recovery.	SOC / incident-response and engineering leads
Days 21–30	Map the cryptographic components and suppliers used by the agent’s identity and connections. Record algorithm, dependency, owner and change path. In a test environment, validate supported key or algorithm rotation and interoperability; align any PQC decisions with CSA’s QRI/Handbook and NIST guidance.	PKI / enterprise-architecture lead with procurement and system owners

Track outcomes that prove control rather than activity: the share of high-impact agents with named owners; unowned or shared credentials remaining; whether an agent can be stopped and revoked in a test; whether action logs connect the agent to its sponsor; and whether priority cryptographic dependencies have a documented replacement and test path. Set targets according to risk and system constraints rather than adopting a generic percentage without context.

What this means for Singapore organisations

Start with the workflows that carry the most consequence: software deployment, cloud administration, finance or customer-data operations. CSA’s agentic-AI addendum offers a local way to think about mapping the workflow and selecting controls, while IMDA’s Agentic AI governance framework stresses meaningful human accountability and technical controls. (IMDA, updated framework, 20 May 2026)

For quantum readiness, use CSA’s updated QRI and Handbook to structure the organisation’s assessment and migration conversation; CSA specifically notes the scale and multi-year nature of migration. Do not assume a vendor’s “quantum-safe” label answers how an agent identity, token issuer, service connection or audit record behaves during change. Confirm the product, algorithm, version, integration and rollback plan with the relevant system owner and supplier.

Make the identity accountable before making the agent autonomous

Agentic AI and post-quantum migration are often discussed as separate programmes. Operationally, both depend on knowing which digital identity is trusted, what it may do, which cryptographic mechanism supports that trust and how change is controlled. Building those seams deliberately reduces the chance that a permission change or cryptographic transition obscures accountability.

KIS’s published AI Security services include AI governance, model and data risk assessments, testing for prompt injection and data leakage, and secure AI adoption. Its Security Assurance & Testing services include source-code assessments with remediation guidance and retesting. If you are introducing agents into development or cloud workflows, talk with KIS about reviewing the authority, identity, logging and change paths around those systems. The right scope depends on your architecture and risk; no assessment can promise that an agent or algorithm will never fail.

Sources

1. NIST NCCoE — Comments on Software and Agentic AI Identity Concept Paper, 29 September 2026
2. NIST NCCoE — Software and AI Agent Identity and Authorization Concept Paper, February 2026 (draft)
3. CSA Singapore — Securing Agentic AI Addendum, 17 June 2026
4. IMDA — AI Agents Insights from the Singapore Government and Google Sandbox, 20 May 2026
5. NIST CSWP 39upd1 — Considerations for Achieving Crypto Agility, updated 29 June 2026
6. CSA Singapore — Quantum-Safe Migration Handbook and Quantum Readiness Index, 16 July 2026
7. NIST — Post-Quantum Cryptography standards and migration guidance
8. IMDA — Updated Model AI Governance Framework for Agentic AI, 20 May 2026