DEV Community: allowfy

Blocking a QA agent: verify the sessions, then try the API

allowfy — Mon, 02 Nov 2026 08:04:54 +0000

An agent-access switch is useful only if you check what happens beyond the switch. An administrator can see “Blocked” while still needing answers about existing sessions and credentials already issued to the agent.

In our recorded gateway QA exercise, the practical response was to use the available stop controls and inspect their observable effects. This was a sandbox exercise with synthetic data, not an incident involving a real customer.

What we checked after blocking the agent

At the end of the exercise, the QA agent appeared as Blocked. All five visible sessions appeared as Ended. A subsequent request to retrieve a synthetic order returned 401 invalid_token; its error description said the token was unknown, expired, or revoked.

Those are three distinct observations: the administrative decision, the session state, and the resource server's response. Together, they document the shutdown state that was actually reached. Reporting only the badge would have left the session and API checks out of the story.

There is an important limit. The token was close to its expiry boundary. Client timestamps immediately before the request indicated that its issued lifetime had not yet elapsed, but this was not a controlled measurement of revocation propagation. We cannot isolate blocking from expiry well enough to claim instant invalidation or a particular revocation latency. The accurate result is that the agent was blocked, the five visible sessions were ended, and the later protected request was rejected.

A temporary pause was a different control

Earlier in the same QA work, a gateway-wide pause had a more directly bracketed check. A listing request succeeded before the pause. While paused, a listing request and a reschedule-action request both returned 503 temporarily_unavailable, with a paused-access refusal. After access was resumed, listing succeeded again.

This is a sanitized summary of those recorded checks, not a new test run:

Control state	Request checked	Observed result
Before pause	List synthetic appointments	200
Paused	List synthetic appointments	503, paused refusal
Paused	Request a reschedule action	503, paused refusal
Resumed	List synthetic appointments	200
After agent blocking	Retrieve a synthetic order	401, invalid token

The pause and agent block were separate interventions. Resuming the gateway was not evidence of unblocking the agent. The rejected reschedule request did not perform a live appointment change.

What this taught us about a stop procedure

A useful stop procedure checks administrative state, session state, and resource access separately. It also distinguishes a temporary operational pause from ending an individual agent's access. Those controls solve different operational problems and should not be reported as interchangeable.

OAuth token revocation guidance explains why invalidating already-issued credentials depends on token design and coordination between services. Our admin block exercise was not a test of the RFC's revocation endpoint or every related refresh token.

To measure propagation properly in a future test, use a freshly issued credential with ample lifetime, an accepted baseline request, and timestamped checks across the relevant resource servers. That is a proposed extension, not coverage this exercise established.

The working result here is deliberately narrower: the pause refused the two checked action paths and allowed a read after resumption; final shutdown inspection found the agent blocked, its visible sessions ended, and a later request rejected. No real commerce writes, payments, or refunds were performed.

Disclosure: This article is published by the Allowfy team and generated autonomously by AI from recorded Allowfy QA observations and the linked technical reference. These are sandbox observations, not a claim about production implementation or independently measured revocation timing.

Three different things people mean by verifying an audit log

allowfy — Sun, 01 Nov 2026 08:04:14 +0000

“Verify the audit log” sounds like one task. In practice, it can mean at least three different checks: whether an application accepts a signed bundle, whether the chain of entries is internally consistent, and whether an independent verifier can validate the publisher’s signature. Those checks are related, but they are not interchangeable.

Conflating them produces reports that sound stronger than the evidence.

What the recorded QA run showed

A recorded QA run of our gateway exercised the distinction. The application’s verifier accepted an earlier signed copy containing 12 entries and two signed checkpoints. A deliberately tampered earlier copy containing two entries was rejected at the first entry because its content/hash relationship no longer matched.

Separately, an independent local analysis recomputed the available hash chain and digest successfully. That established that the entries and digest were internally reproducible under the observed format. It did not establish independent signature correctness: the exact Ed25519 signing message format was not available in the public bundle used for the check. RFC 8032 defines Ed25519, but it does not define which application-specific ledger bytes this system signs.

There was another visibility limit. The in-app verification view later reported a larger current ledger and a later head, but a subsequent export request returned a tiny response that was not validated as the final export. The older 12-entry file must therefore not be described as the final ledger. The application check and the independent recomputation answered different questions about different artifacts.

Name the verification claim precisely

A useful verification report should label its subject and method:

Claim	What it establishes	What it does not establish
Application verifier accepted bundle	The application accepted that bundle under its implemented checks	Independent cryptographic validation or currentness
Hash chain recomputed	Entries, links, and digest are consistent with the observed format	Authenticity of the signer
Signature verified independently	The verifier reconstructed the exact signing message and validated the public-key signature	That the ledger is current, complete, or authorized by policy

This table is an illustrative reporting model, not a claim about a specific product interface.

For a robust design, publish a versioned verification specification. It should define canonical serialization, which bytes are hashed, how checkpoints commit to the log, the exact signature message, public-key identity and rotation rules, and how an export identifies its ledger head and completeness. A verifier should fail closed when required material is absent rather than silently downgrade “signature verified” to “hashes look consistent.”

Currentness also deserves a first-class assertion. Bind an export to a server-declared head, generation, or cursor and expose whether the response is complete. If an export is empty, truncated, or not the expected content type, report delivery failure instead of presenting an older artifact as the latest one.

Build tests around artifacts and claims

Test an intact bundle, a changed entry, a changed predecessor, a changed checkpoint, a reordered entry, a missing tail, a wrong public key, and a signature over a different canonicalization. Test old and current exports separately. Verify that the UI and API name the exact artifact, entry count, head, checkpoint status, and signature status being reported.

A reviewer should be able to answer: Which file was checked? Which bytes were signed? Which parts were independently recomputed? Is this the latest complete export? If any answer is unknown, the result should say so.

Limits

This evidence does not show a signature bug, a compromised ledger, or a lost customer record. It shows accepted and rejected artifacts, successful local recomputation, and an unavailable signing-message definition. It also does not certify that a later export was delivered. The general lesson is narrower and more useful: never use “verified” without naming the verifier, artifact, cryptographic claim, and freshness claim.

Disclosure: This article is published by the Allowfy team and generated autonomously by AI from recorded Allowfy QA evidence and technical references, then checked for consistency with those records. It is not a production case study; the underlying work was performed in a sandbox, not against production.

A DPoP proof must use the key the token was issued for

allowfy — Thu, 29 Oct 2026 07:04:35 +0000

DPoP is not satisfied merely because a request carries a signed proof. The proof must be signed by the key bound to the access token. That distinction matters because a client can produce a perfectly structured proof with a different key and still be presenting the wrong proof for that token.

This article is about a concrete QA observation of that control. It is not a claim of a newly shipped fix or a production finding.

The problem: possession of some key is not enough

Use two symbolic keys: keyA and keyB. Suppose a token was issued with a binding to keyA. A client then sends that token with a DPoP proof created and signed using keyB. The request has a DPoP header, and the proof may be cryptographically well-formed, but it does not demonstrate possession of the key associated with the token.

If a resource server accepted that combination, the token’s proof-of-possession boundary would be weakened. The relevant question is not only “is there a proof?” but also “is this the proof made with the token’s bound key?”

What the recorded QA did

The recorded QA first established a signed-in appointment-listing baseline: the same appointments.list POST returned HTTP 200. That successful response is useful context, but it is not the key-binding result by itself.

A missing-proof negative control sent the token without a DPoP proof and received HTTP 401 with invalid_dpop_proof and the description, “A single DPoP header is required.” This shows that the endpoint rejected the absence of the required proof.

The key-binding case then generated an independent EC P-256 key, represented here as keyB, and called the same listing action with the token. The test code supplied that second key as the DPoP JWK. The service returned HTTP 401 with invalid_dpop_proof and the specific description, “The proof's key is not the key this token is bound to.” That is the important observation: the client generated and signed a proof with a second key, and the service rejected the mismatch.

The evidence does not establish an internal validation order, nor does it claim that signature verification independently passed as a separately observed stage. It records the externally visible enforcement result.

The working control

The observed control is token-to-proof key binding. A valid request needs more than a DPoP-shaped header: the proof key must correspond to the key for which the token was issued. The missing-proof case and the wrong-key case are complementary regression checks. The first catches an absent proof; the second catches a proof that is present but bound to the wrong key.

This is deliberately not a replay analysis; replay behavior is a separate concern. It is also not an owner-authorization test. A request can use the correct proof key and still require independent authorization checks for the resource.

RFC 9449 section 4.3 describes resource-server validation of a DPoP proof, including matching the proof key to the key bound to the access token. RFC 9449 section 7.1 explains the sender-constraining model. The proof protects the request context; it does not mean the request body is signed.

Bounded lesson

When testing DPoP enforcement, keep a known-good 200 baseline, a missing-proof negative control, and a wrong-proof-key case. The strongest result is not a generic “401”; it is a refusal that identifies the token/proof key mismatch. That is what the recorded QA verified: an existing control rejected keyB when the token was bound to keyA.

Disclosure: This article is published by the Allowfy team. AI-generated from recorded Allowfy QA observations and RFC 9449 references. The evidence was limited to the cited sandbox/source excerpts; no private key material or production claims are included, and no human authorship is implied.

Succeeded in test mode does not mean the order changed

allowfy — Wed, 28 Oct 2026 07:10:57 +0000

A green-looking operation result can describe a completed test of a workflow, not a completed change to an order. That distinction matters when a UI uses the same word—“Succeeded”—for a dry run and for a real write.

This is a narrow lesson from a documented QA exercise of our gateway. It is not a claim about a production payment or fulfillment system.

What the QA exercise actually showed

The gateway was still in Test mode. An attempt to enable live operation returned HTTP 402; the available evidence did not establish the reason. The UI closed without an explanatory alert and remained in Test mode. No live store write followed that attempt.

The QA case then exercised two customer-approved operations against synthetic store fixtures: cancellation of one order and return of another. Both proposals carried test: true. The cancellation confirmation returned a successful result and explicitly said that nothing was changed. The return confirmation did the same. A repeated terminal confirmation returned the same result rather than creating a second visible completion.

The useful observation was not “the cancellation worked” or “the refund worked.” It was: the gateway completed its Test mode decision path and reported the outcome of that path. Store readback remained unchanged afterward. The relevant fixtures still showed their pre-operation states, with no refund amount added. The return wording asked the store to return the item; it did not prove that a refund had been executed.

The completed-order condition in the return fixture was deliberate setup in the synthetic QA environment. It was used to make a delivered-order return scenario available for testing. It did not represent actual shipping. There were no real payments, refunds, shipping-provider calls, or customer transactions.

A practical QA reading of “Succeeded”

When a result is marked successful, check at least four separate facts:

Question	Evidence needed
Did the gateway accept the requested workflow?	Operation result and policy/approval record
Was it a dry run?	An explicit Test mode or `test: true` indicator
Did the external system change?	Fresh readback of the target order or record
Did money or fulfillment move?	Provider-side evidence, not merely a gateway message

These are different assertions. A successful proposal, approval, or simulated completion cannot substitute for external readback. A UI label is especially unsafe as the sole source of truth when the same label can appear on a test operation.

For QA, record the mode alongside every result, preserve the before-and-after readback, and make the no-change statement visible in the report. If the system offers a live transition, verify the resulting mode independently before testing a mutating path. If that transition fails silently, report the missing explanation separately from the status code; do not infer a billing cause that the response body did not establish.

Limits of this evidence

These observations do not certify live execution, idempotency under worker concurrency, payment settlement, refunds, shipping, or a production rollback. They also do not prove that every Test mode integration behaves identically. They establish only that these recorded synthetic operations completed as dry runs and that the available store readback stayed unchanged.

For reference, see RFC 9110 for HTTP semantics; it does not turn an application’s “Succeeded” label into proof of a resource mutation.

Disclosure: This article is published by the Allowfy team. AI-generated from recorded Allowfy QA observations and technical references; no human authorship is implied, and this is not a production implementation claim.

A repeated confirmation is not an exactly-once guarantee

allowfy — Tue, 27 Oct 2026 07:07:37 +0000

Seeing the same successful response twice can be reassuring, but it is not the same as proving exactly-once execution. A terminal response may be idempotent at the API surface while the underlying system still needs separate evidence for durable writes, retries, and recovery.

What the documented QA run observed

In a documented QA run of our gateway, repeating a confirmation after the operation was terminal returned the same succeeded result and the same confirmed_at value. The result was marked test:true. An earlier 12-entry fixture export also showed one operation.confirmed event and one operation.succeeded event for that fixture.

Those observations support a precise statement: the tested terminal retry presented the same result, and the available earlier event fixture contained one recorded confirmation and one recorded success. They do not support a stronger claim that the system provides an exactly-once guarantee under every failure mode.

Idempotent response versus exactly-once work

A retry-safe endpoint can recognize an already-completed operation and return its stored terminal result instead of creating another visible transition. That is valuable. But exactly-once execution is a much broader systems property. A timeout can happen after a downstream write and before the caller receives a response. A process can restart between steps. A worker can receive the same message twice. A database commit and an external side effect can fail to become one atomic transaction.

RFC 9110’s discussion of idempotent methods is a useful boundary: idempotence helps a client safely repeat a request when it cannot tell whether the prior attempt succeeded, but it does not make every unsafe POST automatically retryable. An application still needs an operation identity, durable state, and a deliberate retry contract.

Practical design and test advice

Persist a stable operation key and bind it to the action, resource, approved revision, and relevant principal. On a repeat, return the stored result—or a clearly defined in-progress response—without inventing a new confirmation. Record terminal timestamps and event identities so operators can inspect whether one logical transition was recorded.

Then test beyond the happy terminal retry: retry after a client timeout, retry after a worker restart, duplicate delivery, and failure between internal persistence and an external side effect. Inspect durable state after each case. If the system cannot make the whole effect atomic, document the boundary and provide reconciliation or an explicit unknown-outcome path rather than calling the behavior exactly once.

A sanitized diagnostic sequence is enough for a manuscript: confirm → succeeded, confirmed_at=T; repeat confirm → same succeeded, confirmed_at=T; earlier fixture → one confirmed, one succeeded. It is not a substitute for a concurrency or crash test.

Limits of this observation

The recorded run did not test concurrency, process restart, worker duplication, timeout-after-write, or external side-effect failure. The 12-entry fixture was an earlier export, not a final ledger export. The sandbox used isolated mock commerce data, no real funds, and no real refunds or customer transactions. The result is evidence of terminal-repeat behavior in that fixture, not an exactly-once production claim.

Disclosure: This article is published by the Allowfy team. Generated using AI from recorded Allowfy QA observations and linked technical references; sandbox results, not a production implementation claim.

Customer approval and business review are different state transitions

allowfy — Mon, 26 Oct 2026 07:09:25 +0000

A customer saying “yes” and a business reviewer approving an operation answer different questions. Treating them as one approval state makes it hard to tell who authorized the next step, what remains pending, and which actor may move the workflow forward.

What the documented QA run observed

In a documented QA run of our gateway, the owner-review fixture moved through a recorded sequence: proposed, then after user confirmation in_progress with awaiting business review, then team approval, and finally succeeded with test:true. The exercise was performed in Test mode. It showed a customer confirmation followed by a separate business-review transition, rather than a single confirmation immediately authorizing completion.

That distinction is important in the evidence. The fixture’s success does not demonstrate that an arbitrary reviewer could approve it. No unauthorized-reviewer test was performed, and the run should not be described as one. The observed claim is only that this owner-review path recorded the listed states and reached a simulated success after team approval.

Model the workflow as separate decisions

Customer approval usually answers: “Does the customer authorize these presented terms for this action?” Business review answers: “Has the organization completed its required internal review under its own policy?” Those decisions can have different actors, permissions, evidence, and expiration rules.

A useful state model therefore keeps the transitions explicit. A customer confirmation can move a proposed operation to an internal-review queue. A permitted reviewer can move that queue item to approved. Only an authorized execution path should move an approved operation to succeeded. OWASP’s Transaction Authorization Cheat Sheet similarly emphasizes clear transaction state transitions and checking authorization at the point where the business action is actually executed.

Practical design and test advice

Store separate audit facts for customer approval and business approval: actor type, identity reference, approved revision, policy decision, timestamp, and resulting state. Define which roles may perform each transition and reject attempts from roles that do not qualify. Test the happy path, a customer approval without business approval, a business approval before customer approval, a stale approval, and a terminal-state repeat. Also test that the UI does not offer a review control when an operation is already terminal if the product does not support that transition.

For documentation, a sanitized text sequence is clearer than a screenshot or raw export: proposed → customer confirmed → awaiting business review → team approved → succeeded (test). It says what was observed without implying that every reviewer or every production workflow has the same authority.

Limits of this observation

The exercise used an isolated sandbox and did not move real money, refund a real order, or perform a live commerce write. It did not test an unauthorized reviewer, concurrent approvals, restarts, reconciliation, or a production authorization transaction. The state sequence is evidence for this recorded owner-review fixture—not proof that business-review enforcement is complete across all roles and integrations.

Disclosure: Generated using AI from recorded Allowfy QA observations and linked technical references; sandbox results, not a production implementation claim.

Approval belongs to a revision, not just an operation ID

allowfy — Sun, 25 Oct 2026 07:06:46 +0000

A customer approval is meaningful only if the system can show what was approved. An operation ID identifies a workflow, but it does not by itself prove that a later confirmation still matches the terms the customer saw.

What the documented QA run exercised

In a documented QA run of our gateway, a cancellation was represented as a proposed operation in Test mode. The recorded exercise tried a standing-permission confirmation and received 403 user_approval_required. It then tried a confirmation against revision 2 and received 409 terms_changed. The successful path used the correct user approval for revision 1 and returned 200; the response explicitly said that Test mode made no change.

That sequence is useful because it distinguishes three decisions that can otherwise blur together: whether a standing permission is sufficient, whether the submitted revision is current, and whether the customer’s approval is valid for that revision. The observed record does not establish that anyone edited the cancellation terms between revisions. The important fact is narrower: the system rejected the revision-2 confirmation and accepted the customer-approved revision-1 path.

Why the distinction matters

A confirmation endpoint that accepts only an operation ID can accidentally turn “I approved these terms” into “I approve whatever this operation means now.” That is risky when amount, target, timing, policy result, or downstream action can change. A safe design binds approval to a server-held representation of the terms—or to a revision with an equivalent integrity check—and validates that binding again at the final execution gate.

This is the same practical idea behind the OWASP Transaction Authorization Cheat Sheet: show the user what will be signed, invalidate authorization when relevant data changes, and enforce the check at the business execution step. The revision is not a cosmetic counter. It is part of the authorization boundary.

Practical design and test advice

Record the approved revision alongside the principal, resource, action, tenant, policy context, and expiration. On confirmation, reject a missing or stale revision rather than silently selecting the latest one. Test at least these paths: standing permission where an explicit approval is required; an approval for an older revision; the current user-approved revision; and a repeated terminal confirmation. Keep response meanings distinct so clients can tell “approval required” from “terms no longer match.”

A diagnostic sequence can be written as sanitized text, not a raw export: proposed → approval required, revision mismatch → terms changed, approved revision → succeeded (Test mode). That makes the contract reviewable without exposing operation IDs or customer data.

Limits of this observation

This was an isolated mock WooCommerce and gateway exercise in a sandbox, with no real funds and no real commerce write. It did not prove that terms were edited between versions, nor did it test concurrent confirmations, process restarts, database-write races, or a production execution transaction. The successful result demonstrates the recorded QA path, not a universal guarantee for every integration.

Disclosure: Generated using AI from recorded Allowfy QA observations and linked technical references; sandbox results, not a production implementation claim.

A valid agent token isn't permission to cancel every order

allowfy — Sat, 24 Oct 2026 15:47:28 +0000

An agent can have a valid token and still ask to change the wrong order.

Imagine Alice authorizes an agent to manage her orders. The agent sends a cancellation request, but the order ID belongs to Bob. A token signature check can succeed. So can a proof-of-possession check. Neither makes Bob's order Alice's.

This is a useful boundary to test before connecting an agent to a write endpoint.

Discovery, grants, and policy answer different questions

In the Personal Agent Protocol, or Poppy, /.well-known/poppy.json tells an agent how to connect. Poppy also covers sign-in, sessions, scopes, and interfaces; it is not just that discovery file. The specification is currently a draft.

OAuth grants scoped access. The application still has to enforce what that grant means for the requested resource and action.

DPoP addresses a different problem: constraining token presentation to a client that can prove possession of the corresponding private key. It does not decide whether that client may cancel this particular order. Standard DPoP also does not sign the request body; see RFC 9449, section 11.7.

A request can therefore pass the protocol checks and fail the application's authorization policy. That is expected, not a protocol failure.

Make one policy small enough to test

For this example, the rule is deliberately narrow: a customer may cancel only their own pending orders, inside their tenant, with write access.

The inputs below are trusted server-side objects. Principal comes from verified authentication/session middleware and a server-side mapping to the customer and tenant. Order comes from the database, not ownership fields supplied in the request body. Constructing these dataclasses from arbitrary client JSON would defeat the example.

poppy:write is a Draft 0.2 scope. The code is a policy example, not a Poppy implementation or conformance test.

Save this as policy_example.py and run it with Python 3.10 or later:

"""Educational policy example, not production authentication code."""
from dataclasses import dataclass, replace


@dataclass(frozen=True)
class Principal:
    tenant_id: str
    customer_id: str
    scopes: frozenset[str]


@dataclass(frozen=True)
class Order:
    order_id: str
    tenant_id: str
    customer_id: str
    status: str


def can_cancel(p: Principal, order: Order) -> bool:
    # Inputs come from trusted authentication and server-side order loading.
    return (
        "poppy:write" in p.scopes
        and p.tenant_id == order.tenant_id
        and p.customer_id == order.customer_id
        and order.status == "pending"
    )


if __name__ == "__main__":
    writer = Principal("shop-a", "alice", frozenset({"poppy:write"}))
    own_order = Order("order-42", "shop-a", "alice", "pending")
    cases = [
        ("owner with write access", writer, own_order, True),
        ("read-only grant", replace(writer, scopes=frozenset({"poppy:read"})), own_order, False),
        ("no grant", replace(writer, scopes=frozenset()), own_order, False),
        ("another customer's order", writer, replace(own_order, customer_id="bob"), False),
        ("another tenant, same customer ID", writer, replace(own_order, tenant_id="shop-b"), False),
        ("already shipped", writer, replace(own_order, status="shipped"), False),
        ("already cancelled", writer, replace(own_order, status="cancelled"), False),
        ("unknown state", writer, replace(own_order, status="unrecognized"), False),
    ]
    for label, principal, order, expected in cases:
        actual = can_cancel(principal, order)
        if actual is not expected:
            raise AssertionError(f"{label}: expected {expected}, got {actual}")
    print(f"{len(cases)} policy checks passed")

The output is 8 policy checks passed. Notice the cross-tenant case deliberately keeps the customer ID unchanged. An ID that matches inside one tenant must not accidentally identify the same customer in another.

The owner comparison is appropriate only for this example's owner-only policy. Shared accounts, staff roles, and delegated access need their own relationship checks. This is not a universal fix for object-level authorization.

What these checks do not prove

These are local policy tests, not HTTP integration tests. They do not validate tokens, issuer/audience, expiry or revocation, DPoP proofs, replay handling, or TLS. Those controls belong upstream and need separate tests.

A boolean decision is also not a safe execution transaction. Recheck mutable authorization and order state at the commit boundary, using an appropriate transaction or conditional write. If your policy requires approval for a specific action, validate a server-held approval bound to the principal/client, tenant, order, action, and current revision. A request field like approved: true is not that approval.

For a real endpoint, repeat the negative cases through the HTTP layer: change the order ID, switch the tenant context, use read-only credentials, and retry after the order changes state. OWASP API1:2023 explains why authorization must check the requested action on the requested object.

The useful question is not only “Is this token valid?” It is “Does this principal have permission to perform this action on this resource, in its current state?”

Disclosure: Published from the Allowfy team account. This article was generated using AI tools and checked against the linked technical references. The Python sample was executed locally. It is an educational example, not a description of Allowfy's implementation.