Authenticated customer portal AI: from search to completed task

Login proves who someone is. It doesn't prove what they're allowed to change, or that the change happened.

Two records describe the same Tuesday request, and they disagree. The portal's chat log says the downgrade request was resolved: an article on plan changes was shared, and the ticket was marked deflected. The subscription record for account JF-1048 still says Team plan, 25 seats.

The customer in this illustrative case is Avery Bennett, billing contact at Juniper Freight, and the vendor is Brightmoor Cloud. All three are invented. The mismatch isn't exotic, though. Avery asked an authenticated customer portal for a change and got an explanation.

Nothing broke, yet the job wasn't done. Finding the right content, confirming identity, checking account authority, taking an action, and proving the result are five separate events. A deflection report can collapse them into one.

The chat's answer versus the portal's record

The chat answered a question Avery never asked. Avery didn't want to know how plan changes work. Avery wanted the plan changed.

Every cell on the left is accurate. None of it says the customer's job is done, so a dashboard that reads only that column is measuring reading, not service.

That's the line between retrieval and completion. Retrieval returns content. Task completion means the requested, permitted outcome happened. Identity was confirmed, authority was checked for this account and action, and the outcome can be proven.

Proof lives in the system of record, the application that owns the truth, such as the billing or subscription platform. A help-center search API shows the gap. It returns ranked article objects and snippets, but it doesn't change a subscription, however relevant the result.

Not every completed task changes a record. Sending an authorized contact an existing invoice completes without editing anything, so a read-only request can finish without a mutation. A plan change can't. Its proof is a confirmed new state.

Which tasks an agent in your authenticated customer portal may finish, and which it may only explain, is your policy choice. It isn't a platform default. Broad customer service automation software decisions need that sharper question once a customer has signed in.

Walking the request from sign-in to readback

Here's the same request handled properly, in the order it happens. The policies are Brightmoor's invented rules, and any checkpoint can stop the request.

Checkpoint 1: who is asking

Avery's session came from the vendor's single sign-on. Brightmoor requires a fresh one-time code for billing changes, so the agent asks for one before going further. Avery enters it.

That settles identity and nothing more. Authentication tells you who is asking. Authorization tells you whether this person may do this exact thing to this exact object.

Checkpoint 2: what Avery may change

The subscription record lists Avery as the authorized billing contact for JF-1048. Brightmoor allows a mid-cycle downgrade only when active seats fit the new plan. Juniper Freight has 8 active seats, and Starter allows 10.

This is the checkpoint that's easiest to skip, and it's where discovery and completion part ways in customer self-service software. OWASP's API security guidance calls the failure broken object-level authorization: a logged-in person reaches records that aren't theirs. Its fix is a check on every function that takes a record ID from the client.

That rule has teeth for AI agents in two ways. An integration may hold broader credentials than any one customer has. If it does, those credentials can't expand what Avery may request or see. The agent applies Avery's authority for this account and action, not its own reach.

Permission to read isn't authority to change, either. Avery could view invoice history without being allowed to change the plan. So authority is evaluated for the exact resource and action at execution time, not when the conversation started. The requester-authority model behind that rule is covered in AI agent authorization.

Checkpoint 3: the one permitted action

Before submitting, the agent pins down the action and its fence. Permitted: change JF-1048 from Team (25 seats) to Starter (10 seats), effective today. Prohibited: making that change without the fresh code, for anyone but the billing contact, or with more than 10 active seats.

No credit or refund is issued under this policy, so no money moves. The agent re-checks Avery's role at the moment it submits.

Checkpoint 4: accepted, then executed

The billing API returns HTTP 202 with an illustrative job ID, PC-5512. Under RFC 9110, the HTTP standard from June 2022, a 202 means accepted for processing, not completed.

So the agent doesn't infer success. It polls job PC-5512 until the billing system reports status completed for the JF-1048 plan change. The API response is an event, not an outcome.

Checkpoint 5: readback and acceptance

Then the agent reads the subscription back: plan Starter, seat limit 10, effective October 13. Only a readback of the same record shows the change happened.

Now Avery hears it: the change is live, and 8 of 10 seats are in use. Avery opens the portal's subscription page and confirms it shows Starter. The case closes with the readback attached and a reopen flag set to review the next invoice.

The record you keep

Write that trail down as separate states, never one "resolved" flag. The labels below are illustrative worksheet names for this proposed method, not fields in any product. Fill them in per task type before you configure anything, and they become your test script.

Illustrative comparison – A retrieved article is not a completed plan change; confirm the authorized new state in the subscription system.

Both columns start with the same article. Only the left one holds evidence that the subscription changed. You can merge rows, but never collapse submitted, executed, and confirmed into one status.

DevRev describes Computer, by DevRev, through the same contrast in how Computer approaches support resolution. An answer helps, but a confirmed change finishes the job.

When the answer has to be no

A good refusal is specific, doesn't leak, and leaves the customer a next step. Here are three more invented requests on the same account, each starting from the original Team plan.

Role-blocked. Rory Navarro, another person on the Juniper Freight account, asks for the same downgrade. Rory's role is member, so the agent doesn't submit or execute anything. It explains that plan changes need the account's billing contact.

Then it offers the route Brightmoor's policy allows: a billing-review request from Rory's own session. Rory sends it, and the plan stays Team until the billing contact acts.

Cross-account. Avery asks to downgrade account JF-2207 too, but Avery has no link to that account. OWASP's guidance warns against revealing whether a record exists to someone not allowed to know. So the agent says, "I can't find an account you can manage with that ID," whether JF-2207 exists or not.

The next step belongs to the right person. An authorized admin of the intended account can sign in and request the change through their own verified session. The agent doesn't link accounts on the spot, and any account linking would need its own separate authority review.

Policy-blocked, then handed off. Suppose Juniper Freight had 14 active seats, so a mid-cycle move to Starter isn't permitted. The agent tells Avery that 4 seats must be removed first, then offers a handoff. Rae Lindqvist, a Brightmoor billing operations specialist, accepts the case with the gathered context.

Rae now owns the case, but Avery's plan hasn't changed. The task stays open until a readback shows Starter.

These paths are worth counting on purpose. Useful buyer-designed measures include retrieved-only versus confirmed-result counts, identity-failure handling, and handoff acceptance time.

They're also the quickest test of any portal agent. Run one role-blocked and one cross-account request on test data. The refusals should reveal nothing about other accounts, and the handoff should reach a named owner. For the completed case, ask for the readback itself: system, field, new value, and time, not an HTTP status or job ID.

That same evidence standard applies if you're evaluating Computer against a portal task you define.

Where the job actually ends

Avery's proof isn't the chat transcript. It's the subscription page: Starter, seat limit 10, effective October 13, with 8 of 10 seats in use. Avery can open it without asking anyone.

That's the bar for any authenticated customer portal agent, and it's a fair one to hold a vendor to. Pick one of your own portal requests and walk it through to the readback with DevRev. Ask which steps Computer supports in your configuration and which stay with your billing system.

One check still comes later. Next month's invoice should bill Starter. If it bills Team, the reopen flag fires and the task is open again. The record, not the conversation, decides when the job is done.