What is it?
AI agent security is the set of controls that governs what an agent can access, which actions it can take and how its behaviour is monitored and contained. An agentic AI system can select tools and combine steps towards a goal, deciding which information to retrieve, which API to call and what to do next.
The opportunity is real. Agents can take repetitive investigation work off engineers and help them reach useful decisions sooner. The business benefits depend on knowing where that assistance ends and authority to act begins.
Two questions help clarify the scope: what is the agent authorised to do, and how independently may it do it? AWS’s agentic AI governance framework distinguishes these as agency and autonomy. A system that prepares a change for approval needs different controls from one authorised to execute it independently.
Why it matters
Risks
- An agent may misunderstand a task, encounter malicious instructions in retrieved content or call a compromised tool. AWS’s secure agent access guidance discusses these risks, including prompt injection and tool poisoning.
- Broad permissions increase the possible impact. The operating question is therefore both what the agent should do and what its access would allow if something went wrong.
Costs
- AWS describes autonomous agents as the most significant shift in security posture since the move to cloud, and calls for continuous detection and response as agentic workloads evolve.
Operational impact
- That shift is visible in operations tooling. AWS DevOps Agent became generally available on 31 March 2026, bringing together telemetry, code and deployment information to support incident investigation and operational improvements.
- AWS added release management capabilities in preview in June, including reviewing changes for production readiness and testing releases. Release management remains labelled preview in the documentation reviewed for this article.
Strategic impact
- Investigation, recommendation and execution still need to be distinguished. A recommendation alone does not establish authority to change production, so the operating model must define where authority sits.
Five controls your operating model needs
Establish agent identity and ownership
- Start with agent discovery: identify the agents already connected to your environment. Include experiments, coding assistants and integrations introduced by individual teams.
- For each one, record its purpose, business owner, technical owner, connected tools and approved environments. Make someone responsible for reviewing changes to that record.
- Agent identity should make activity attributable. Where an agent acts for a user, preserve that user’s authorisation context as well. A shared administrator login makes it harder to understand who initiated an action and which authority applied.
Limit access to the task
- Apply least privilege to the resources, actions and data the agent actually needs. Use appropriately scoped roles and temporary credentials where supported. Keep development and production access distinct.
- For an investigation workflow, ask whether access to selected metrics and sanitised logs is sufficient. Permissions to alter infrastructure should require a separate decision.
- A prompt saying do not change production cannot enforce an access boundary. AWS’s guidance recommends deterministic IAM controls around agent access. Where an MCP server exposes tools, review its downstream permissions too. These are familiar AWS Zero Trust Security concerns, now applied to software that chooses its next action dynamically.
Define human approval before execution
- Make approval rules specific enough to implement. Ask a human when necessary leaves the most important decision unresolved.
- The following is an illustrative starting point, to adapt to the workload. Read approved metrics and sanitised logs: allow within a defined investigation scope. Prepare a remediation plan: allow drafting, and record supporting evidence. Restart a production service or change capacity: require approval unless a tested runbook explicitly permits the action within defined limits. Expand permissions, delete production data or transfer sensitive information: require explicit authorisation through a controlled workflow.
- Enforce the approval gate in the execution path, outside the model’s discretion. The reviewer should see the proposed action, affected resources, expected impact and recovery approach. This keeps human oversight focused on consequential decisions without requiring an engineer to approve every routine observation.
Make monitoring useful to the responder
- The person responding to unexpected behaviour needs to reconstruct the relevant activity. Record the initiating request, agent identity, tool calls, approvals, affected resources and outcomes.
- AWS CloudTrail can contribute AWS API activity, with relevant logging enabled. It does not provide the whole application workflow. AWS’s governance guidance explains the need to combine API-level records with application-level tracing and appropriate invocation logging.
- Decide which events deserve attention: repeated denied requests, unexpected destinations, abnormal tool use or activity beyond the approved scope. Assign someone to respond. Protect the logs themselves, since prompts and tool responses may contain sensitive information.
Include agents in lifecycle management
- An agent’s access needs can change when a team adds a tool, replaces a model or expands its responsibilities. Treat those changes as review points.
- Maintain a versioned record of its configuration, permissions and evaluations. Test changes before release, and make the retirement process remove credentials, integrations and scheduled execution.
- Also define how to stop it. Pausing a schedule may leave an active run or queued action untouched. The owner needs a tested containment procedure covering the agent and the systems through which it acts.
Common mistakes
Letting an agent act through a shared administrator login
Consequence: Activity is no longer attributable, so it is unclear who initiated an action and which authority applied.
Avoidance: Give each agent an identity that makes activity attributable, and preserve the user authorisation context when it acts for someone.
Relying on a prompt instruction to hold an access boundary
Consequence: A prompt saying do not change production cannot stop an over-permissioned agent from doing so.
Avoidance: Enforce deterministic IAM controls around agent access and review downstream permissions where an MCP server exposes tools.
Expanding autonomy after a successful demonstration alone
Consequence: A demonstration shows a task can complete, but not how the agent behaves when a task is ambiguous or a dependency fails.
Avoidance: Test the boundaries in an isolated environment before widening what the agent may do unattended.
Best practices
- Use an isolated environment and synthetic data to test requests outside scope, misleading retrieved content, unavailable tools and partial execution.
- Check whether a retry could repeat a consequential action.
- Verify that prohibited actions are blocked by the underlying controls and required approvals cannot be bypassed.
- Confirm the resulting records are sufficient to investigate an incident.
- Test the containment procedure, and repeat relevant evaluations when the model, tools or access change.
How to get started
- Choose one agent already connected to AWS and bring its technical owner and platform owner together.
- Trace a single task from request to outcome.
- Identify the credentials used, resources reachable, approvals enforced and records produced.
- Test one action the agent must refuse.
- Use the findings to prioritise the next change.
Excessive access, missing approval gates or an untested stop procedure should be addressed before expanding the agent’s responsibilities. Start where a failure would most affect production, then widen the exercise once that gap is closed.
How KineticSkunk helps
KineticSkunk’s Cloud Platform Engineers build or take over AWS platforms and operate an agreed scope through AWS Managed Platform. That operating model connects access, monitoring, change, incident response and continuous improvement.
For teams introducing agents, the useful starting point is agreeing how those responsibilities apply to the platform and where application ownership remains with the customer. Our published approach to AI-assisted incident triage uses read-only investigation, with production changes and remediation under human review. Useful automation needs clear authority behind it, so the scope must be explicit.
Give agent authority the same discipline as any other production change. The access boundaries in this article build on AWS Zero Trust Security for least-privilege identity and deterministic IAM, applied to the platform your agents run on through AWS AI Cloud Infrastructure.
Pair this with AWS Cloud Operations: How the Best Teams Run AWS when you want ownership, recovery and change control on the same review.
Frequently asked questions
Define its purpose and owner, constrain identity and access, enforce approval boundaries and record its activity. Test those controls before production and review them when its tools, model or responsibilities change.
Key risks include excessive permissions, prompt injection, compromised tools, sensitive data exposure and unintended actions. Weak activity records or an ineffective containment procedure can make incidents harder to manage.
Trust should be specific to the task, access scope and tested controls. Begin with limited authority and assess whether the benefits justify expanding it. Human approval remains appropriate for consequential actions outside established, validated automation.
No. Read access can expose confidential information, and an agent may pass retrieved data to an external service. Limit what it can read, control destinations and protect sensitive content in its logs and responses.
