An agentic development platform combines a language model with tools, code context, and a loop that can plan and act. The practical question is not whether it can generate code; many can. The practical question is whether the team can state what it is allowed to touch, how its work will be checked, and who owns an undesirable result. Engineering leaders should approach it as a change to the delivery system, not as a personal productivity utility. It affects source-code access, review capacity, test infrastructure, secrets handling, and the expectations placed on maintainers. NIST's AI Risk Management Framework offers a disciplined way to connect those benefits and risks to named decisions. For this part of the system, name the accountable owner, supporting evidence, exception route, and next measurable check.
What authority should an engineering agent have?
Start with the least authority that can demonstrate value. Read-only exploration and draft explanations are lower risk than branch writes; branch writes are lower risk than opening pull requests; production changes and external communications are materially different again. Authority should be granted per workflow, repository, and environment, not as a blanket property of a tool subscription. A build-break investigation may need access to logs and a sandbox, while a documentation task may need neither. Make the platform disclose its proposed actions before execution and make the enforcement layer, rather than the model alone, decide whether an action is permitted. This keeps policy reliable even when a prompt or tool response is confusing. Within this part of the system, name the accountable owner, supporting evidence, exception route, and next measurable check.
| Question | Reasonable first answer | Why it matters |
|---|---|---|
| May it read all code? | Only approved repositories and paths. | Limits data exposure and misleading context. |
| May it run commands? | Only controlled commands in isolated environments. | Protects workstations and shared services. |
| May it create changes? | Yes, on reviewable branches. | Preserves inspection and rollback. |
| May it deploy? | Not in an initial rollout. | Deployment carries customer-facing consequence. |
How should generated changes be reviewed?
Review the same outcome a human-authored change would require: business intent, design assumptions, affected contracts, tests, migration behavior, security implications, and observability. Ask the agent to prepare evidence rather than accepting a narrative about what it did. A reviewer should be able to see the diff, commands run, failures encountered, source context, and unresolved uncertainty. Keep tasks small and independently verifiable; a large generated refactor can hide too much reasoning in one review. In areas with specialized risk, such as authorization, payments, privacy, or safety, route the change to the relevant owner. The NIST SSDF remains applicable because the delivery obligation belongs to the organization, regardless of who drafted the code. When implementing this part of the system, name the accountable owner, supporting evidence, exception route, and next measurable check.
How should code context and secrets be protected?
Use the smallest useful context and assume repositories contain sensitive material: credentials accidentally committed, customer examples, internal endpoints, and design decisions not intended for broad sharing. Establish where prompts, tool traces, and code snippets are processed and retained. Give the platform scoped credentials that can be revoked and avoid passing production secrets into a conversational window. Test its behavior when an issue or file asks it to reveal instructions, download a package, or run an unrelated command. OWASP's prompt injection guidance is relevant because untrusted text may arrive from many places in a development workflow. Controls need to be technical, not merely training reminders. Before releasing this part of the system, name the accountable owner, supporting evidence, exception route, and next measurable check.
| Asset | Control to establish | Verification |
|---|---|---|
| Repository context | Path and project allowlists. | Attempt out-of-scope retrieval. |
| Credentials | Short-lived, service-specific tokens. | Revoke token and confirm denial. |
| Build environment | Sandbox and network restrictions. | Run an unsafe-command test. |
| Agent traces | Documented retention and access policy. | Review deletion and audit paths. |
How can a team evaluate real value?
Choose representative tasks and compare the entire workflow: understanding the issue, producing a change, reviewing it, testing it, deploying it, and supporting it after release. Track defects, rework, time spent in review, abandoned tasks, and developer confidence alongside cycle time. Do not use generated-token volume or accepted suggestions as a proxy for value. Ask maintainers whether the change was understandable six weeks later. Evaluation should include failure cases, such as an incomplete specification, conflicting code conventions, a broken dependency, or an adversarial instruction in a ticket. The NIST Generative AI Profile supports this focus on context-specific measurement and continuous monitoring. While operating this part of the system, name the accountable owner, supporting evidence, exception route, and next measurable check.
Who should govern platform changes?
- Engineering owns workflow fitness, review practice, and technical quality signals.
- Security owns the minimum safeguards for data, credentials, tool access, and incident response.
- Platform owners manage approved integrations, environment boundaries, and service reliability.
- Product or delivery leaders define which outcomes and customer commitments may be affected.
- A named decision group approves material expansions of authority or data access.
Governance should be visible in normal engineering work, not an occasional committee meeting. Maintain a registry of enabled tools, repositories, permissions, approved workflows, and exceptions. Require a review when a new connector, model, or external action is introduced. Keep an incident route for a leaked secret, unsafe command, or misleading change, including a way to suspend access quickly. The companion agent permissions checklist is useful for turning broad principles into a concrete entitlement review. When changing this part of the system, name the accountable owner, supporting evidence, exception route, and next measurable check.
What rollout questions should be answered?
Before broad rollout, confirm that pilot users understand the tool’s scope, reviewers have enough context to assess changes, and support teams can identify which changes involved the platform. Decide what happens when the agent service is unavailable so teams do not lose the ability to deliver. Document how to opt out for sensitive work and how to report a harmful result without blaming the user. A pilot should end with a decision about specific workflows, not a vague decision to adopt or reject AI. That precision lets the organization retain what worked and tighten what did not. During support for this part of the system, name the accountable owner, supporting evidence, exception route, and next measurable check.
How does ownership stay visible?
Assign a named owner to the platform configuration, but do not make that person the owner of every generated change. Repository maintainers remain accountable for their code, security teams for risk controls, and delivery leaders for customer impact. The platform owner coordinates policy, telemetry, and support. This separation prevents a common confusion in which a tool administrator becomes an invisible approver for work they cannot meaningfully review. Make the ownership model visible in pull-request templates, incident routes, and entitlement reviews. To validate this part of the system, name the accountable owner, supporting evidence, exception route, and next measurable check.
Revisit the model after a significant change in workflow or capability. A new connector, a larger context window, or permission to call a deployment tool can alter the risk far more than a routine version update. Capture the change, test representative failures, and notify the engineers who depend on the platform. Deliberate maintenance is what turns a promising experiment into a service that people can safely use every day. To govern this part of the system, name the accountable owner, supporting evidence, exception route, and next measurable check.
Key takeaways
- Grant authority by workflow and environment, beginning with the smallest useful scope.
- Review generated changes with the same evidence expected of any production change.
- Protect code context, secrets, and tool access through enforceable boundaries.
- Measure end-to-end delivery quality rather than activity produced by the platform.
- Govern changes to models, connectors, and permissions as changes to the delivery system.
Frequently asked questions
Will an agent replace engineering judgment? No. It may reduce some mechanical work, but someone still has to understand requirements, tradeoffs, and operational consequence. Is a code sandbox sufficient security? It is useful but not sufficient; context, credentials, network access, and downstream tools also need boundaries. Can every repository use the same policy? A shared baseline helps, but a payment service and an internal prototype usually require different authority. When should autonomy increase? Only after the team has evidence that a narrowly defined workflow is reliably reviewed, monitored, and recoverable. When explaining this part of the system, name the accountable owner, supporting evidence, exception route, and next measurable check.
Conclusion
The right question is not whether an agent can act, but whether the organization can explain and control the action it is about to take. Build from bounded assistance toward proven authority, and keep human accountability at the points where context and consequence matter most. The related AI agents for approvals planning guide offers another perspective on designing those decision points. For this part of the system, test one expected case, one ambiguous case, and one failure with a documented recovery action.
An operating note for this decision
For teams evaluating an agentic platform, publish examples of work it should decline as prominently as examples of work it can accelerate. Include incomplete requirements, cross-tenant data requests, unreviewed production changes, and tasks requiring domain approval. Engineers need permission to stop a run without feeling that they have failed to use the tool effectively. Collect those decline cases as a living policy test. They help reviewers identify when a new capability should remain disabled and make a future expansion of authority a deliberate engineering decision.