The Hook Between Intent and Action

Picture a product team with several changes moving at once. One agent thread traces a failing deployment across two repositories. Another investigates a dependency upgrade. A third prepares a bounded refactor while a developer reviews the plan from another device. People still own the decisions, but the work no longer fits inside one editor session or one model request.

That team may move between browser AI, a desktop assistant, a command-line agent and a remote agent platform during the same week. Security cannot treat those surfaces as interchangeable. Each platform changes where organisation policy can honestly meet an agent that reads, writes and acts across a long-running task.

Amp is an important addition to this fast-moving field. It makes much of the agent lifecycle programmable, giving teams durable threads and remote environments while exposing meaningful moments around inference and tools.

Promptective supports Amp through managed policy checkpoints for direct prompts, tool calls and tool results. The path from Amp’s lifecycle events to a precise working boundary also explains why its technical direction deserves attention.

Amp made the agent lifecycle programmable

In May, Amp, Rebuilt described a new foundation as “remote-controllable, compaction-first, plugin-powered, and much faster.” The phrase captured a serious architectural bet: agents would work for longer, across more environments, while developers gained durable control points around the loop.

The Amp Plugin API is the part that made the integration possible. Plugins can react to agent lifecycle events, tool calls and tool results. They can also add tools, commands and UI. Amp later brought plugin UI to the web in Plugins, Everywhere.

For security teams, the important feature is timing. Amp exposes an event before a tool runs and another after the tool finishes but before its result returns to the model. It also exposes the start of a direct agent turn. Those are meaningful decision points, because the host still holds the next inference or side effect.

Amp’s recent release trail reads as one coherent operating model. Agents in Orbs gave agents fresh remote machines and room to work in parallel. Secrets of the Orb added short-lived OIDC workload identity with workspace, project, user and thread claims. Projects with Multiple Repositories gave one project the context to cross repository boundaries. Amp on iOS and macOS brought Orb control into a developer’s pocket.

Each feature reinforces the same idea: the coding agent is becoming an operating environment for software work. Amp has pursued that idea with unusual speed and architectural conviction.

The first sketch changed shape

The first integration sketch put a local evaluator inside the plugin. It looked familiar because Promptective already protects supported desktop code-assistant paths close to the workstation.

The sketch exposed a policy problem. A local fallback and a managed organisation policy could drift, producing two answers for the same team. Amp’s Orb identity created a cleaner path. The plugin could stay thin, exchange short-lived workload identity for a thread-bound Promptective session and ask the organisation’s Managed Cloud policy for each supported checkpoint.

That choice gave teams one current policy model and content-minimised operational evidence. Supported prompt, tool-call and tool-result content is processed transiently for the decision. Routine health, logs, dashboard records and protection receipts exclude that plaintext.

Four Amp events form the integration spine:

• session.start establishes the session for an eligible thread.
• agent.start checks a supported direct prompt before onward inference.
• tool.call checks a proposed tool action before side effects.
• tool.result checks held structured output before it returns to the model.

The event names look compact. Making each one honest took most of the engineering.

The message arrived one step earlier than expected

The first raw challenge came from prompt timing. Amp has already accepted a direct message when agent.start runs. The hook can cancel the turn, yet it cannot atomically rewrite the message already stored in the thread.

That detail changed the claim and the recovery experience. The protected boundary became onward inference. When policy returns a non-allow prompt decision, Promptective cancels the turn, shows a fixed explanation and keeps the user on an edit-and-resubmit path. A separately evaluated safe edit can continue. The original message stays out of inference through the protected turn.

This boundary is narrower than pre-ingress protection and more useful than a vague promise. Teams can see the exact moment policy applies and what the user can do next.

Structured data demanded stricter transformations

Tool calls and tool results created a different challenge. Amp can hold both at strong lifecycle boundaries, and supported structured data can sometimes be made safe while preserving the task.

The tempting implementation was a broad text replacement. That would risk corrupting a tool contract or changing an identifier the agent depends on. The integration instead makes transformation conditional on strict shape, identity and path checks. A valid transformation preserves the expected structure. An invalid or ambiguous transformation stops at the hook.

The result is a useful split:

• Direct prompt findings use cancel, explain, edit and resubmit.
• Supported tool-call and tool-result findings can use a verified structured transformation.
• Ambiguous shapes stop before the held boundary continues.

A cold start looked like a security finding

The next challenge appeared during a slow first session. Bootstrap crossed its expected window and the early implementation surfaced the delay as though policy had found sensitive content.

That was the wrong story for the user and the wrong evidence for Security. The fix separated three states: a confirmed content decision, an authoritative disconnected workspace and an unavailable or ambiguous service condition.

A confirmed content decision follows organisation policy. An explicitly disconnected workspace lets Amp continue and shows that Promptective protection is inactive. A genuine outage or ambiguous identity response follows the safe failure policy for the authenticated session. Cold availability can warn and retry without creating a durable content-policy quarantine.

One rough timeout produced a clearer product contract.

Configured plugins can lose precedence

Amp supports Project, System, Personal and Workspace plugin locations, with documented precedence when names collide. That flexibility is excellent for teams and development. It also means a configured workspace plugin can be displaced by a higher-precedence copy.

Distribution and runtime evidence therefore became separate records. The Amp workflow uses a reviewed plugin artefact with declared version, manifest, hash, size and control origin. Changes move through the chosen plugin repository and its normal review path. Silent replacement stays outside the design.

The dashboard places intended distribution beside workload sessions and recent hook-specific policy decisions. Teams verify plugin precedence as part of rollout, keeping session evidence distinct from executor attestation. This is the kind of detail Amp gets right as a platform: extensibility remains visible and inspectable.

Thread identity had to survive the distributed system

Orbs made managed identity possible and also created the hardest trust-boundary test. A session needs to belong to the Amp workspace, project, user and thread that requested it. The plugin-reported active thread must agree with Amp’s signed workload identity before enrolment is consumed or an installation is created.

During qualification, a child execution path presented its owning Orb’s thread claim. The IDs differed. The integration rejected the mismatch before creating an installation. Supported Orb-owned direct sessions keep an exact binding; runner and CLI child threads remain outside current coverage while that identity lane evolves.

That outcome matters. Distributed agent systems create pressure to accept a nearby identity and keep moving. Amp’s thread claims provide enough context to preserve the exact boundary.

What teams get

An organisation administrator opens Agent Integrations > Amp. The workflow creates a one-use enrolment credential and generates a reviewed installation prompt for either a Project pilot or Workspace distribution. Project scope is useful for qualification with one repository. Workspace scope carries the approved plugin across the team.

The installation prompt verifies the plugin artefact before a fresh eligible Amp session establishes the binding. The dashboard then shows Amp workload sessions, supported hook boundaries and recent hook-specific policy decisions. Content-minimised activity and receipts preserve policy, decision, reason and checkpoint facts.

When an administrator explicitly disconnects the Amp workspace, the installed plugin becomes inactive and non-blocking. Each supported direct message tells the user that Amp is continuing without Promptective protection. Re-enrolment restores the active path.

What Amp support covers

When a recent managed decision at one of these supported hooks matches the current valid policy, Promptective reports the integration as hook-partial coverage. The label keeps the promise tied to the lifecycle events Amp exposes:

• Direct prompts: checked before onward model inference on the protected turn.
• Tool calls: checked while Amp still holds the proposed action before side effects.
• Tool results: checked before the held structured result returns to the model.
• Operational evidence: policy, decision, reason and checkpoint facts remain content-minimised in routine records.

Generated assistant output, provider-network traffic, full assembled model requests, pre-Amp message ingress and runner or CLI child threads remain outside this integration’s current coverage. Higher-precedence plugins can also change which copy is effective, so teams should verify plugin precedence during rollout.

Amp in the way modern teams work

Thorsten Ball’s account of Putting an Agent in an Orb ends with a memorable principle for agent-friendly systems: “don’t make them guess.” Give the agent a paved path, observable errors and a way to verify its work.

That principle is also a useful standard for security integrations. Teams rarely conduct every AI-assisted task in one surface. Research may begin in a browser, implementation may move through a desktop or command-line assistant, and longer work may continue in a managed agent environment. Each deserves a control shaped around what the host can actually hold, change and prove.

Amp stands out because these pieces form a coherent platform. Its plugin API provides meaningful lifecycle hold points. Orb OIDC provides short-lived, granular workload identity. Project and Workspace plugins give teams a reviewable path from pilot to wider use. The raw challenges sharpened how the integration uses each primitive.

Amp moves quickly, cuts old assumptions without sentimentality and keeps turning ambitious ideas into primitives other teams can build on. That combination of product velocity and technical depth is rare, and it makes Amp an important platform to support well.

The security layer should follow the team without flattening those platform differences. For Amp, that means bringing organisation policy into the loop at the moments where supported intent becomes inference, a tool call becomes an action and a tool result becomes new model context. Amp support extends Promptective’s coverage across model runtimes and AI platforms while preserving the exact boundaries of this integration.

Explore Amp protection to map the integration to your team’s workflow.

Sources

• Amp: Amp, Rebuilt, published 6 May 2026.
• Amp Docs: Plugins, reviewed 29 August 2026.
• Amp: Plugins, Everywhere, published 28 May 2026.
• Amp: Agents in Orbs, published 30 June 2026.
• Amp: Putting an Agent in an Orb, published 2 July 2026.
• Amp: Secrets of the Orb, published 14 July 2026.
• Amp: Projects with Multiple Repositories, published 27 August 2026.
• Amp: Amp on iOS and macOS, published 28 August 2026.

Reviewed by Promptective Product and Security on 29 August 2026. Amp features and integration boundaries can change. Review the linked sources and current Promptective coverage before relying on a specific path.