Treat the agent as a governed non-human identity with separate permissions for reading, analysing, and writing. Require explicit approval before code changes are created or merged, log every context source the agent used, and limit the ticket types that can invoke it. The goal is to preserve accountability while still reducing routine triage effort.
Why This Matters for Security Teams
When an AI agent can read tickets and open pull requests, it is no longer just an analysis tool. It becomes a governed non-human identity with execution power, data access, and a path into software delivery. That changes the risk from “bad output” to “unauthorised action,” which is why current guidance increasingly treats agent permissions as a security boundary rather than a productivity setting. The SailPoint report on AI agents as a new attack surface found that 80% of organisations said their agents had already acted beyond intended scope.
Security teams often get this wrong by giving the agent broad read access to tickets and then allowing it to write code as a convenience feature. That shortcut collapses review, attribution, and least privilege into one control plane. The safer pattern is to separate read, analyse, and write permissions, and then require human approval before any code change is created, let alone merged. That aligns with the emerging direction in the OWASP Top 10 for Agentic Applications 2026 and the NIST AI Risk Management Framework.
In practice, many security teams encounter agent sprawl only after a bot has already touched sensitive tickets, generated risky code, or exposed context that was never meant for automation.
How It Works in Practice
Governance works best when the agent is treated like a scoped workload identity, not a human user with an assistant attached. The core question is not “What can the model understand?” but “What can this identity do, at this moment, for this specific task?” That is why static RBAC alone is usually insufficient for agentic workflows. A ticket-reading agent needs one set of permissions, a code-authoring agent needs a narrower set, and a merge-capable agent should usually not exist without explicit approval gates.
In practice, teams separate the workflow into three controls:
- Read access limited to approved ticket queues, labels, or project namespaces.
- Analysis rights limited to approved data sources and logged context retrieval.
- Write actions constrained to draft pull requests, never direct commits or merges.
Runtime policy checks should decide whether the agent may move from one stage to the next. Best practice is evolving toward intent-based or context-aware authorisation, where the decision depends on the task, the ticket type, the repository, the time window, and the approval state. That approach is more consistent with agentic systems than fixed access tables because the agent’s behaviour is dynamic and goal-driven. Where possible, teams should issue short-lived credentials per task and revoke them automatically when the job completes. This reduces the blast radius if the agent chains tools or begins following a broader path than intended.
For identity plumbing, current guidance increasingly favours workload identity primitives such as SPIFFE/SPIRE or OIDC-backed tokens so the agent proves what it is before it gets anything sensitive. The operational lesson is to log every context source, every ticket reference, and every tool call, then tie those logs to approval records. That is also where NHIMG research on Top 10 NHI Issues and lifecycle processes for managing NHIs is especially relevant, because credential lifecycle and auditability are usually where controls fail first.
These controls tend to break down in fast-moving engineering environments where ticket queues, code repositories, and CI/CD systems are loosely coupled because the agent can traverse systems faster than approval workflows can keep up.
Common Variations and Edge Cases
Tighter control often increases friction for developers and support teams, so organisations must balance delivery speed against the risk of unauthorised code creation. That tradeoff is real, especially when the agent is meant to reduce triage backlog rather than become a production change engine.
There is no universal standard for this yet, but current guidance suggests three common exceptions need special handling. First, low-risk ticket classes such as documentation fixes can be allowed to auto-draft pull requests, while security, access, or billing tickets should remain human-approved. Second, agents that read many tickets but write into only one repository should be segmented so that context access does not imply code-write authority. Third, when the agent uses external tools or shared prompts, the organisation should treat those inputs as part of the security boundary and record them for audit.
One practical issue is that review teams may assume a pull request is harmless because it is “only a draft.” In agentic systems, drafts can still leak secrets, embed unsafe dependencies, or create a misleading review trail. That is why the CSA MAESTRO agentic AI threat modeling framework and the NIST Cybersecurity Framework 2.0 are useful reference points: both reinforce governance, logging, and controlled execution. NHIMG’s OWASP NHI Top 10 also underscores that agent mis-scoping is rarely a single failure; it is usually a chain of overly broad context, weak approval logic, and missing revocation.
For organisations operating in regulated or high-change environments, the safest default is to keep merge authority human-only and treat agent-created pull requests as suggestions, not trusted changes.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Agentic misuse and overbroad tool access are central to this question. |
| CSA MAESTRO | AIC-03 | MAESTRO covers agent task boundaries, approvals, and tool-use governance. |
| NIST AI RMF | GOVERN | AI RMF governance applies to accountability, oversight, and auditability. |
Model ticket-to-PR flows as separate stages with logged approvals and constrained execution rights.
