Agent identity & security

Give it an identity.Not your admin account.

An agent needs an owner, an identity and a limit to its authority. Control what it can reach, what it can change and how its access is removed.

Explore the capability
ENGINEERING FOCUS
01Identity and owner
02Policy at execution
03Audit and revocation

The model does not grant permission.

Treat model output and retrieved content as untrusted input. The systems executing actions must enforce the permission boundary, regardless of how convincing a request sounds.

01

Know what is running.

Record the agent, its owner, purpose and connected resources. Distinguish its own identity from actions performed on behalf of a person.

02

Restrict execution.

Apply least privilege, short-lived credentials, network controls and sandboxing where appropriate. Separate reading, drafting and committing changes.

03

Test and revoke.

Exercise prompt-injection and misuse scenarios. Log relevant actions, protect the logs and provide a tested way to stop work and revoke access.

A possible workflowIllustrative example.

An agent can retrieve approved information and draft a change, but cannot publish it without a separate approval.

Guardrails can fail. Use layered controls and test them at the system boundary rather than relying on a prompt to enforce security.

A closer look

Good questions.
Straight answers.

Is a prompt a security control?

Not a sufficient one. The system must independently enforce authentication, authorisation and permitted operations.

Do you guarantee that agents cannot be misused?

No. We define the threat model, engineer layered controls and test relevant failure cases. Residual risk and operational ownership must remain explicit.

Technical reference: Microsoft: agent identities (opens in a new tab)