Put policy at the call boundary you own
Runtime protection evaluates an agent’s API call at the point where the application can inspect input, decide whether to dispatch and inspect the completed outcome. AGINDOW brings the Dependabot for agents idea to runtime: configured detection supplies findings, verified selective repair may adapt eligible reviewed changes, and the chosen mode controls the policy decision. This boundary does not guarantee correct business actions or replace application authorization, vendor idempotency, retries or credentials. The published SDKs are pre-alpha tools for local evaluation; no generally available hosted guard service is offered.
Label writes before inspecting them
A generic callable cannot tell whether it mutates vendor state. Use operation: write in Node or operation="write" in Python for calls that create or change state. Use unknown when effects are uncertain. A read label is not a harmless default for a callable that transfers money or updates a customer. Begin in observe with controlled fixtures: observe never mutates or blocks the call, so it does not enforce write protection. Detection selection and selective repair remain separate configuration decisions.
Example: distinguish the two halt phases
Before dispatch, a request-phase policy halt can refuse the upstream operation. After the upstream has returned, a response-phase halt can report unresolved drift and retain available outcome evidence, but it cannot reverse the write. Consider an order-creation API returning an unexpected amount: inspect dispatch status and the retained response before deciding to send another order. An error reaching the agent is not evidence that the vendor created nothing.
{"request_halt":"Upstream dispatch refused","response_halt":"Upstream may already have completed; reconcile outcome"}Understand fail-open and fail-closed decisions
Observe preserves outcomes. In repair mode, reads can continue degraded; unresolved shape writes can pass through when upstream will reject, while unresolved semantic writes fail closed because a valid-looking request could silently produce the wrong result. Strict halts unresolved drift including reads and requires at least 0.99 for eligible verified repairs. An internal engine fault bypasses inspection in every mode. These conditional rules depend on available evidence and do not turn strict into an unconditional availability or protection guarantee.
Reconcile uncertainty before a retry
A timeout can happen after the vendor committed a write. Check vendor state and retained outcome evidence before replaying. Preserve the same vendor-enforced idempotency key for the same logical operation where supported; a fresh key can create another write. Review receipts, process-local replay caches and local audit events do not provide distributed exactly-once execution. A receipt records a decision, not permission to execute or replay an operation.
Evaluate protection separately from detection
Test request refusal, response outcomes, untouched payload preservation, independent verifier refusal and internal-fault bypass as separate behaviors. Check whether your configured detectors have representative windows and whether the selected adapter can capture a complete supported body. The read-only playground can help inspect an API response but cannot demonstrate write protection. Keep detection evidence, applied repairs and vendor-persisted correctness distinct when presenting evaluation results.
Publication and evaluation
Published 28 October 2026; last updated 28 October 2026. AGINDOW documentation team. These explanations describe pre-alpha SDK behavior for local evaluation, not production accuracy or reliability benchmarks. Start with the runnable quickstart and evaluate your own boundary before widening scope.