AI coding agents need more than secure code.

A coding agent fixes an authorization bug. The patch passes review, the tests pass, and the team merges it. During the task, however, a helper script had access to production credentials. Nothing in the final diff tells the reviewer whether that script used them.

This is a hypothetical example, but it captures a practical gap in AI coding agent security. A team needs to evaluate the software an agent produces, the actions it takes while working, and the tools it continues to use. Each needs its own checks and records.

Our approach starts with one workflow and follows it from the assigned task to the running software. That makes it easier to see which checks belong in development, which permissions must hold during execution, and what needs another review when the environment changes.

Follow the work behind a patch

Consider an agent asked to fix a billing API. A user can request an invoice from another customer account by changing the invoice identifier. The task is to enforce account ownership, add tests, and open a pull request. It does not require production customer records or permission to deploy.

The agent can read the repository, run tests in an isolated environment, and use an MCP server to retrieve test failures. MCP, the Model Context Protocol, connects an agent to tools and data sources. The agent also loads a project skill: a set of instructions that may refer to scripts or other resources.

There are several things to verify. Does the patch enforce ownership on the server? Can a dependency installation run a script with access to credentials? Can the MCP connection return instructions that persuade the agent to upload a file? Will the team learn if the connector’s installed version is later found vulnerable?

A test that answers one of these questions leaves the others open. The agent harness—the software that runs the agent’s loop and connects it to tools—is part of the environment under review.

One task / Three places to checkFix the billing API without expanding the agent’s access

1. 01 / The change
   Check account ownership

   Test that an authorized user can read an invoice and another account’s user cannot.

   Keep

   The exact patch revision and both test results.

2. 02 / The agent’s actions
   Keep production access outside the task

   Limit the workspace, credentials, tool parameters and network destinations.

   Keep

   Access decisions and the receiving systems’ records.

3. 03 / The installed tools
   Revisit the connector when evidence changes

   Compare its installed version and configuration with a new advisory or upstream change.

   Keep

   The matched component, source, affected machines and owner.

Make findings useful while the agent is working

Give the agent the application’s security requirements before it edits the code. For this task, specify that account ownership must come from the authenticated server-side identity, not a customer identifier supplied in the request. Explain where authorization belongs and which existing tests describe the expected behavior.

Then run checks that can return useful evidence during the task: secret scanning, supported static analysis, dependency checks, and focused tests. A result should identify the file or component, explain the condition, and give the agent something it can verify after a change.

For an unfamiliar repository or skill, Aguara provides local inspection of agent instructions, tool configuration and dependencies. Its documented aguara audit . command combines content inspection with known-malicious package checks without installing the project’s dependencies or executing its commands. That is a useful check before granting the project access to a development environment. It is separate from general vulnerability coverage and application authorization testing.

Keep the check’s policy outside the material being evaluated. A repository should not be able to suppress its own blocking finding through a configuration file that the organization never approved. Aguara’s current audit behavior makes this distinction explicit in its documentation; check the behavior of the version integrated into your workflow.

A deterministic result is repeatable for the same inputs and rules. It can still be incomplete or wrong. Test the checks against examples your team understands, decide which findings stop a task, and give uncertain findings an owner. If a check fails to run, preserve that state as unavailable rather than reporting zero findings.

Test the rule the application is supposed to enforce

The billing patch needs a test that crosses the account boundary. Create two test accounts with separate invoices. Confirm that each account can read its own invoice, then request the other account’s invoice using the same authenticated session. Check the response and whether any protected fields were returned.

Exercise the paths that reach the same data: direct lookup, search, bulk export and any background job involved. A fix to one API endpoint may leave another path unchanged. Source review helps identify those paths; testing checks what the assembled system actually permits.

An AI reviewer can suggest where to look, but a plausible explanation is a starting point for investigation. Record a reproducible request, the identity and test data involved, the expected result, and what the service returned. For issues that cannot be reproduced, say what evidence is missing instead of presenting them as confirmed findings.

Retest the exact revision proposed for release. A passing run on an earlier commit does not validate a later edit. Keep the successful account-access case too: a patch that denies every request may stop the exposure while breaking the product.

This is where Oktsec Assessment fits: scoped testing of applications, APIs and agent workflows, with reviewed findings and reproducible evidence. The targets, permitted actions and stop conditions are agreed before testing. AI-assisted investigation does not remove that scope or the need to validate the result.

Constrain the agent doing the work

Now return to the helper script. Even if it produces the correct patch, it may run with every credential available to the agent’s process. An instruction to use test data cannot revoke a production token inherited through the environment.

Give the task a workspace and an identity that match its needs. Use synthetic billing records, a limited test-service account and a branch where the agent can propose changes. Keep production secrets and deployment authority in separately controlled paths.

Tool permissions need enough detail to distinguish useful work from an unrelated action. Allowing read_file by name alone says nothing about which files it may read. Allowing an HTTP tool says nothing about where it may send data. A shell can provide alternate paths to both operations.

Oktsec Control applies policy to actions routed through configured enforcement points. Depending on the integration, those checks can restrict tools, parameters and destinations. Coverage still depends on the route: an MCP gateway cannot control a separate shell or network connection that bypasses it. Test those alternatives and use operating-system, network and service permissions to enforce the remaining limits.

An approval should identify the proposed action, its target and the revision being authorized. If the request changes, the old approval should not silently authorize the new operation. For our billing task, opening a pull request and deploying the patch are separate permissions.

Our analysis of prompt injection and authorization develops this distinction. Malicious instructions in a tool response matter because the agent may have access to something consequential. Restricting that access reduces what a successful redirection can accomplish.

Keep checking the tools already in use

A week after the billing patch ships, the team receives an advisory about the MCP connector. No one changed the application, but the evidence used to approve the connector has changed.

Start with the installed component. Record its package ecosystem, resolved version or commit, where it was observed, when it was last observed, and who owns it. A repository name alone is often insufficient: the installed package may be a fork, a different release or a transitive dependency.

OSV provides structured vulnerability information that can be queried using package and version or commit information. The GitHub Advisory Database is another source of security advisories. GitHub repository changes and research found through web search can add context. A search result mentioning the same tool is a lead to validate, not an affected-version match.

Keep three situations separate. An old MCP release may need an update but have no known vulnerability. A package version may match an advisory, while the reported exploitation conditions still need checking. A skill may contain risky instructions without any CVE identifier at all. Each needs a different explanation and response.

Proposed monitoring workflowTurn an external report into a decision about your environment

1. SourceA connector advisory appears

   Keep its identifier, affected versions and publication history.

2. MatchCheck the installed component

   Confirm package, version, configuration and inventory age.

3. ResponseGive the owner a concrete action

   Update, restrict access or investigate. Record what remains unconfirmed.

Close the alert with new evidence

Observe the replacement version and repeat the relevant test. An approved update request does not prove that every affected machine has updated.

This is the continuous monitoring direction for Oktsec Signal: connect the tools discovered by Node with security advisories, upstream changes and research, then make the affected component and required review clear. Aguara powers Signal’s inspection foundation. The inventory-to-intelligence monitoring integration is in development; it should not be confused with a fully deployed alerting service today.

The value of that monitoring is specific: a team should be able to answer which employee computers still have an affected package, which skill revision needs review, and whether the expected correction was observed. Node inventory supplies evidence from configured collection. Missing or stale reports must remain visible as gaps.

An external finding should not silently rewrite runtime policy. Depending on the impact, an owner may approve an update, temporarily restrict a tool or request further testing. New observations should update the same issue instead of producing a fresh alert on every scan. Our agent supply chain analysis explains why instructions, connectors and their dependencies all belong in this review.

Keep evidence that answers the next question

For the billing task, the pull request should link to the tested revision and the authorization tests. The agent’s activity records should identify the policy used, the privileged requests evaluated and any approvals. The release system should supply its own deployment result.

These records have different meanings. A request was proposed; a control allowed it; a destination accepted it; the expected state was observed. A timeout between those steps leaves an unresolved outcome. Retrying a write without checking that outcome may perform it twice.

Oktsec Cloud brings policy, inventory and review evidence together across reporting systems. Its records need to be read within the coverage of those systems. A signed entry helps establish integrity and origin; it does not establish that every possible action was captured or that an allowed operation completed.

Preserve identifiers and results useful to an investigation without copying credentials or customer data into the audit trail. Our guide to evidence for agent work goes into the records needed to reconstruct a decision.

Start with one workflow your team already runs

Choose a task with a clear owner and a meaningful permission, such as changing a billing API or preparing a deployment. Walk through it with development and security staff. Write down the required behavior, the access the agent actually receives, and the records available when something fails.

The following checks form a practical acceptance review for our example. They are proposed tests, not results from a customer engagement.

Swipe or scroll horizontally to compare all columns.

Use the results to decide the next change. That may be a better code check, a narrower credential, a missing inventory field or a test for a path the team had overlooked. Revisit the checks when tools or permissions change. This gives the team a concrete basis for letting agents take on more work.

Sources and further reading

• Aguara documentation: inspection scope, commands and project-policy handling. Standalone engine coverage is not a claim that every integration ships the same features.
• OSV documentation and the GitHub Advisory Database: sources for identifying and matching disclosed software vulnerabilities.
• Oktsec Research: What is an AI agent harness?, prompt injection and authorization, and the agent supply chain.