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.
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 capabilityEngineering 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.
Restrict execution.
Apply least privilege, short-lived credentials, network controls and sandboxing where appropriate. Separate reading, drafting and committing changes.
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 workflow
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.
How do you stop agents being misused?
By never relying on the model to police itself. Each agent gets its own identity and the narrowest permissions that work, consequential actions wait for a person, and every action is logged. Then we attack it ourselves, with prompt injection and misuse scenarios, before it goes live.
Technical reference: Microsoft: agent identities (opens in a new tab)
Keep exploring