Between July 17 and July 23, Amp shipped five releases that turn its coding agents from session-bound tools into persistent, always-on services: agent-to-agent messaging, a meta-agent with Slack integration, self-scheduling, multiplayer orbs, and event-driven orbs. The interesting part isn't the feature list — it's the trigger security model buried in the changelog. Amp split its inbound triggers into two tiers. GitHub-originated events get cryptographic signature verification and a deliberate separation between trusted metadata and untrusted content. Everything else — the general-purpose event trigger — runs on a durable webhook URL that Amp's own documentation calls a credential, because anyone holding that URL can invoke the agent. That's a real distinction, and it matters because Amp got the outbound side right just nine days earlier, replacing static outbound secrets with short-lived OIDC workload identity. The team clearly understands mature credential design. It just hasn't applied the same standard to the door agents come in through. A durable capability URL is bearer-token security: possession is authorization, with no rotation schedule, no audience binding, no delegation chain to inspect after the fact. This is a live instance of the gap the identity community has been naming abstractly all year. Coverage of the release notes that a webhook URL trigger effectively functions as a credential — anyone holding the URL can invoke the agent — which is exactly why unsigned trigger paths are the softest part of an otherwise hardening system. The broader argument circulating alongside it is that agent identity has to cover every artifact that grants the power to act, not just which API key gets used, because a borrowed credential makes an agent indistinguishable from the human it's acting for. None of this has been picked up by independent press yet — it's documented only in Amp's changelog and API reference. That doesn't make it less real; it means anyone building on top of agent-as-a-service platforms should read the primary release notes directly rather than wait for a security advisory. The pattern here — strong outbound identity, weak inbound trigger identity — is unlikely to be unique to one vendor. As more coding agents move toward persistent, schedulable, delegatable operation, the trigger surface, not the agent's own credentials, becomes the place where authorization actually gets decided.