Investigating blocked AI agent calls without weak controls

Blocked AI agent calls are not friction to eliminate. They are the part of your control system that tells you where the agent's instructions, tool interface, access setup, or behavior stopped matching reality. If you treat every denial as a request for more permission, you will eventually give an agent the broadest authority at exactly the moment you have the least reason to trust its next move.

I have watched teams turn a useful denial into a permanent exception because a deadline was loud and the evidence was scattered. The first approval feels harmless. The second approval feels routine. Soon an agent can reach production with a credential it never needed to see, through a tool nobody can explain cleanly. That is not an efficiency gain. It is an investigation you chose not to perform.

Investigating blocked AI agent calls means answering a narrow set of questions in the right order: what precisely did the process request, which control refused it, did the task justify that request, and what is the smallest repair that lets legitimate work continue? The order matters. Start by widening access and every later record becomes harder to interpret.

A denial record is evidence, not an error message

A blocked request records a disagreement between an agent's attempted action and the authority you intended to grant. Keep that disagreement intact long enough to understand it. A denial can expose a missing credential, an unapproved process, an overly vague tool, an incorrect environment, or a request that should never have been made.

The term "blocked" blurs two different events that teams often mishandle. An action can fail because it lacks authorization in the gateway, or it can reach an external service and fail there because the service rejects it. The first event says your control stopped the request. The second says you allowed the request to leave, then the destination refused it. Investigate the first before it becomes the second.

A useful record answers questions that a console transcript usually cannot:

• Which agent process made the request, and how was that process identified?
• What exact HTTP operation or SSH command did it request?
• Which destination and credential reference did it select?
• Which gate or approval condition denied it?
• What task instruction or repository context led to that request?

Do not accept "the agent needed deployment access" as an answer to any of those questions. Deployment access is a category. An investigation needs an operation, a target, and an expected outcome. "Read the current release status from the staging API" is a claim you can test. "Deploy access" is an invitation to approve whatever shows up next.

NIST Special Publication 800-92, Guide to Computer Security Log Management, makes the unglamorous point that logs support incident response and operational troubleshooting. The part teams skip is preservation: the log must retain enough context to distinguish an ordinary mistake from an abnormal request. An approval popup alone is not a record. A copied terminal line is not a record. Capture the surrounding run and the individual call before anyone changes a setting.

Denials have a second benefit: they force the human operator to state what authority was intended. That statement becomes a test for the next agent run. If nobody can state it without broad words such as "admin," "production," or "repository access," the task is not ready for autonomous execution.

Name the requested action before changing access

You cannot investigate a blocked call until you reduce it to a sentence that another engineer could reproduce. The sentence should name the actor, action, destination, authentication reference, and expected result. If a record omits one of those pieces, stop treating it as a simple permission request.

For HTTP, capture the method, path, hostname, and whether the call reads or changes state. GET /releases/current and POST /releases may use the same service and credential, yet they create very different risks. A bearer token that can read a status endpoint may also be able to trigger a deployment. Do not infer safe scope from a friendly credential label.

For SSH, record the host alias, requested command, working directory if the tool exposes one, and the expected artifact. "Run tests on build host" is still too loose. "Run git status --short in the checked-out repository" gives a reviewer something concrete to compare against the stated task. Commands that contain shell redirects, command substitution, package installation, deletion, or a network transfer deserve more attention because their visible verb may hide the consequential part.

Use this compact investigation note while the run remains available:

Run identity:
Task instruction:
Requested operation:
Target host or API path:
Credential reference:
Control that denied it:
Expected result:
Why this request belongs to the task:
Smallest safe repair:

That note prevents the familiar handoff failure where one person sees the prompt, another sees an approval card, and a third sees the destination's error response. Each person holds a plausible fragment, so somebody approves on faith.

Sallyport's session authorization leads with the process's code-signing authority, which is the right detail to inspect before approving a new run. Process identity does not prove the request is wise, but it prevents you from treating every local process as interchangeable. A terminal launched by the expected signed application and an unknown executable asking for the same action are different cases.

Do not use the free-text task description as proof. Agents can misunderstand it, inherited instructions can conflict, and a malicious repository can plant instructions that read like ordinary project guidance. Compare the requested action to a task source you control, such as a reviewed ticket or an explicit operator instruction. Repository text is input, not authority.

The denial source changes the investigation

Different controls deny for different reasons, and each reason has a different repair. Treating all denials as a single "permission denied" bucket produces bad fixes because it hides where the decision occurred.

A locked vault denial means no action should proceed. Do not respond by moving the credential into an environment variable, copying it into a prompt, or creating an alternate code path. Those moves bypass the exact protection that caught the issue. Confirm that the person at the Mac intends to unlock access for this task, then resume only after that person has reviewed the run context.

A new-session denial means an agent process has not received authority for its current run. Review the process identity and task boundary. If they match the work you initiated, per-session approval is appropriate because it grants a limited lifetime: the run ends, and that authority ends with it. If the process identity surprises you, do not approve it merely because its requested call looks harmless. An unfamiliar process can use a harmless first call to establish a pattern of trust.

A per-call approval requirement means the credential owner deliberately marked each use for a human decision. Do not remove that condition because the agent is making several similar requests. Ask whether the task was shaped poorly. A batch operation may need a separate, deliberate workflow, not a sequence of click-through approvals that makes a reviewer stop reading.

An absent or mismatched credential is different. The agent might request a named operation that belongs to its task, but the vault has no credential for that destination or the credential does not have the required external service scope. First confirm that the destination is intended. Then add or repair the narrow credential mapping. Never hand the secret to the agent to diagnose the problem. The gateway can perform the authentication while the agent sees only the result.

An external authorization failure requires yet another response. The call may have left through the gateway correctly, but the service could reject it with a response such as 401, 403, or a domain-specific error. Preserve the request shape and the returned result. Repair the service account's scope only after confirming that the attempted operation belongs to the task. Changing a service role before that check turns an ordinary setup issue into broad standing access.

The distinction has a practical consequence: a gateway denial protects the boundary you set, while an external rejection tells you your boundary already permitted the attempt. Do not call both events "blocked" in incident notes. Use separate labels. Your future self will need to know whether the request was stopped locally or merely failed downstream.

Reconstruct intent from the task, not the agent's explanation

An agent can explain why it made a request, but its explanation is evidence about its reasoning, not a justification for access. The task owner decides whether the action belongs. This sounds obvious until an agent says it needs a broad command "to inspect the environment" and the operator is tired of blocking it.

Start with the requested outcome. If the task says to fix a failing test, an API call that reads build status may fit. A call that rotates a deployment credential does not fit unless the task explicitly concerns credentials. If the task says to update documentation, an SSH request that installs packages on a shared host needs a far stronger explanation than "the build requires it."

Then examine the shortest path to that outcome. Agents often choose a broad action because broad actions are easy to describe. A tool that accepts arbitrary shell text invites the agent to use discovery commands, environment inspection, and composite scripts where a named operation would do. A tool that asks for an arbitrary API URL invites it to explore endpoints outside the task.

I use a simple test: could you write a narrow expected-action statement before the agent runs? If you can say "read the current issue labels" but cannot say "modify labels," a write call is not an ambiguous request. It is outside scope. Deny it and investigate the instruction path that produced it.

This is where teams make a popular but bad recommendation: give the agent broad read access because read-only access is safe. Read access can expose customer data, internal topology, deployment details, access patterns, and secrets accidentally stored in a service. It may be less destructive than a write, but it is still authority. Limit read operations to the service, resource class, and environment that the job needs.

Prompt instructions are also weak evidence because repository content can steer an agent. A dependency installation script might include a comment that tells an agent to inspect a local credential directory. A setup document might request a curl command to an unfamiliar host. The agent may follow that text faithfully while still doing something you did not authorize. Treat untrusted repository instructions as data that needs review when they cause a new external action.

Write down the mismatch in plain language. "The task requested a release-status read; the agent asked to create a release." "The task named staging; the request targeted production." "The tool description implied a known host; the request supplied a new hostname." Those statements help an engineer fix the cause. "Denied by security" does not.

Repeated denials usually expose a tool contract defect

A tool interface causes trouble when it hands security decisions to the model in the form of open-ended parameters. The agent then guesses a host, a branch, a path, a credential, or a shell command. Every denial looks like an access problem even when the actual problem is that the tool never defined the allowed action.

Consider an agent asked to check whether a release completed. A loose HTTP tool might allow any method, any URL, arbitrary headers, and a credential selector. The agent constructs a request to an endpoint it found in repository text. It gets denied. Someone approves the destination, then the agent selects a different endpoint for a follow-up. The operator sees a series of individually plausible calls and slowly builds an unreviewed API client through approval decisions.

A better tool exposes the operation you actually support: read release status for a named environment. The tool owner fixes the base destination and HTTP method. The agent supplies a small parameter such as the release identifier. The gateway injects the credential only for the intended call. A denial now has a clear meaning: the requested environment, identifier, process, or credential mapping did not match the contract.

The same rule applies to SSH. Do not give a coding agent a general remote shell when the work needs two maintenance actions. Expose those actions as scripts with known arguments, or use a wrapper that validates a narrow command form. A restrictive interface feels inconvenient when you design it. It feels sensible the first time an agent asks to run a compound command against the wrong host.

Look for these patterns in a cluster of denials:

• The agent repeatedly invents destination names or API paths.
• A request alternates between read and write calls without a task change.
• The same task needs many unrelated credentials.
• Approval requires a reviewer to infer shell effects from a long command string.
• A tool description promises an outcome but leaves the consequential parameters open.

Do not patch each instance with a new exception. Change the tool contract. Narrow tools also improve the agent's reliability because they remove decisions that language models handle poorly. An agent should choose among supported operations, not assemble its own security boundary from strings.

Sallyport keeps secrets in its encrypted vault and executes HTTP or SSH actions without handing credentials to the agent. That separation is useful only if the action interface is specific enough for a human to judge. Credential isolation stops secret leakage; it does not make an overbroad action request acceptable.

Follow one failed run all the way through

A denial investigation should preserve sequence, because the first unusual call often explains every later request. Reviewing only the final blocked action creates a false story in which the agent suddenly became suspicious.

Take a realistic example. An agent receives a task to update a service's release notes after a successful staging build. It begins by reading files in the repository. It then requests an HTTP call to obtain the staging build status. The call fits the task and succeeds after the expected run authorization. Next, it requests SSH access to a build host to inspect a generated artifact. That may be justified, but it is a new channel and deserves a fresh comparison with the task.

The host returns an error because the expected artifact is absent. The agent reads a repository script that says an operator can rebuild artifacts by running a command remotely. It then asks for a command that clears an output directory, installs dependencies, and runs the build. The request receives a per-call denial.

Do not approve that command merely because the first HTTP request was legitimate. The original task did not say to rebuild, alter a shared host, or install dependencies. The tool path changed from status checking to remote modification. The correct investigation asks:

1. Did a human authorize rebuilding the artifact, or did the agent infer it from repository text?
2. Is the build host meant for autonomous changes, or should the agent report the missing artifact?
3. Can a dedicated build operation replace a compound remote shell command?
4. Does the output directory belong to this task, or could clearing it affect another run?
5. Does the task need a different workflow because the staging build did not succeed?

The repair may be to stop and report the absent artifact. It may be to add a reviewed build action with an isolated workspace. It might be to correct the pipeline that should have produced the artifact. Granting general SSH authority is the worst repair because it hides all three possibilities under a single broad permission.

This sequence also explains why approval fatigue is a design failure. A human who sees one normal call, followed by several technical requests, starts approving based on momentum. The control still technically works, but the review quality decays. Put decisions at meaningful boundaries: a new process, a credential with high consequences, or a scope change. Do not force a person to interpret a novel shell program every few seconds.

Trust the audit trail only after checking its integrity

Logs can help only if you can tell whether somebody changed them after the event. A plain append-only claim does not settle that question when the machine running the agent has been compromised or an operator has a reason to tidy an embarrassing record.

A hash-chained audit log connects each entry to the prior entry. Changing an earlier ciphertext changes the chain relationship that follows it. This makes tampering detectable during verification. It does not make the original event correct, and it does not prevent an attacker from doing harm before the event gets recorded. Use it for what it provides: confidence that the retained sequence has not silently changed.

Run the verification before you start a long review and again if you export records for an incident. Sallyport can verify its encrypted audit chain offline with this command:

sp audit verify

The command does not need a vault key for the verification check. Preserve its result with the investigation note, along with the time you ran it and the set of records you reviewed. If verification reports a failure, stop relying on the affected sequence as a complete narrative. Preserve the underlying files, restrict access to the machine, and compare with independent evidence such as destination service logs, repository history, and the task system.

Do not overstate what independent logs solve. A destination service may record that a request arrived, but it may not know which local agent process initiated it. A source control record may show a commit, but it cannot show why the agent chose that change. Correlation works when you retain identifiers and time order across sources, not when you collect screenshots after the fact.

Separate the two questions in your notes. First: "Did this agent run request this action?" Second: "Was the requested action appropriate?" Audit integrity helps with the first. Task scope and human judgment decide the second. Teams blur them because an intact log feels authoritative. An intact log can prove that a bad request occurred. It cannot transform the request into a good one.

Repair the narrow cause and prove the repair

The right repair allows the intended task to proceed while preserving the reason the control denied the original request. Any repair that merely makes the popup disappear is suspect.

For a missing access case, add a credential reference that maps to the intended service and confirm the external scope supports only the needed operation. Re-run the same narrow request. Do not test the repair by trying a broad action "just to make sure." A test should prove the specific failed case now works and that unrelated requests still fail.

For an unexpected process case, launch the known agent entry point again and compare its identity with the denied process. If the expected process has changed because of an upgrade or wrapper, document that change and review why the identity differs. If nobody can explain it, do not paper over it with a permanent approval. Agent tools often run child processes; that does not mean every child deserves the parent's authority.

For a tool defect, change the interface before the next autonomous run. Replace arbitrary destinations with a fixed one where possible. Replace arbitrary command text with a named operation. Move a sensitive parameter out of the agent's control. Then exercise both sides of the boundary:

• The supported request succeeds with the intended process and task.
• A different destination, command, or write operation is denied.
• The activity record identifies what happened clearly enough for a reviewer.
• The session record lets you revoke the run if its behavior changes.

For a suspicious request, do not continue the run while you debate scope. Revoke its authority, preserve the session and call records, and inspect the instruction sources that preceded the request. A normal task can become unsafe after it reads untrusted content. The fact that the process began as an approved run does not grant it a blank check for later actions.

Sallyport projects run and call journals from one write-blind, encrypted, hash-chained audit log, and it supports immediate run revocation through the Sessions journal. Use that revocation when the request sequence stops making sense. It is a containment action, not a verdict on the developer who started the run.

Finish the investigation with one sentence that could guide the next operator: "The agent lacked the staging status credential, which we added for the approved read operation," or "The agent attempted an unapproved remote rebuild after following repository text, so we stopped the run and will expose a reviewed build action." If you cannot write that sentence, you have not found the cause yet.

Make denials cheaper to understand than to bypass

People bypass controls when investigation costs more than the task feels worth. The answer is not weaker controls. It is records and tool interfaces that make the legitimate path obvious and the unusual path visible.

Keep task instructions bounded. State the environment, the intended external action, and the stopping condition. "Investigate the failed staging deploy and report the cause" leaves room for a report. "Make production match staging" quietly invites writes, credentials, and system changes that nobody has reviewed.

Give reviewers enough context to make one decision well. A session approval should show who started the process and what run it belongs to. A sensitive action approval should show the operation and destination in terms a human can understand. If the reviewer needs to decode a credential name, trace an opaque URL, and mentally execute a shell pipeline, your process has pushed the security work into a hurried click.

Measure recurring denials by cause, not by volume. Ten requests blocked because an agent chose an unsupported endpoint indicate a tool problem. Ten requests blocked because a new process appears each run indicate an identity or invocation problem. Ten requests blocked because a task keeps expanding indicate a planning problem. The count alone tells you little.

Do not try to make autonomous agents feel like ordinary scripts. Scripts usually receive authority because a human wrote and reviewed their exact behavior. An agent selects behavior while it runs and can incorporate new repository content, tool output, and errors. That is why an action gateway needs a human decision path and a record that survives the moment.

The next denied call should produce a better task or a better tool, not a broader exception. If your team adopts that rule, denials become less frequent for the right reason: the agent receives clear, narrow authority, and the remaining blocks identify behavior worth stopping for.