What I'd test before Rindler automates a login-walled portal

Rindler launched with a straightforward pitch: describe the web work your team still does by hand, connect the site, and let the automation repeat it on schedule.

The part that caught my attention is what happens behind the login. Rindler says it can maintain site-scoped access, extract records, download documents, submit forms, send messages, and perform higher-impact actions when a user permits them.

That is useful. It also creates a security boundary worth examining:

How does the system keep untrusted portal content separate from the authority a user has granted?

Can portal content change what the task is allowed to do?

A browser agent reads pages it does not control. Supplier notes, support tickets, document titles, and page elements can all contain text that looks like an instruction.

I would test whether page content can change the destination of a message or upload, move a task from reading to submitting, widen the set of records being accessed, switch the site or account in use, or change the permission mode applied to an action.

The policy should win every time. A page can provide data. It should not be able to rewrite the job or grant itself more authority.

Where are the action rules enforced?

Rindler publicly describes per-site rules such as Allow, Ask first, and Never. That is a sensible control surface. I would want to know what enforces those rules.

If the model interprets the policy, I would test whether ambiguous page actions can slip through. A button labeled "Continue" might submit a form. Downloading a report might also trigger an acknowledgement or message. The visible label does not always describe the real effect.

I would want deterministic code below the model to check the effect the browser is about to cause, not just the name of the tool the agent planned to call.

Does site-scoped access stay scoped when something goes wrong?

Rindler says retained sign-in state is encrypted and limited to one site. I would test that boundary during concurrent tasks, retries, redirects, subdomain changes, and unexpected domain changes.

One automation should not be able to reach another site's cookies, captured fields, screenshots, files, or run history unless the user explicitly connected them. Failure paths matter here. Isolation that works only during the happy path is not enough.

What happens when a scheduled task reaches a consequential step?

A read-only check at 3 a.m. is one thing. A form submission, message, order, or payment action at 3 a.m. is another.

For an Ask first action, I would check that the task pauses safely, shows the exact action and destination, expires cleanly, and resumes without replaying earlier side effects. I would also force retries around the approval boundary. A network timeout cannot be allowed to turn one submission into two.

Can the audit trail explain the result?

Screens and step logs are helpful, but they do not tell the whole story. A production audit record should include the policy decision, the source of the input, the account and site involved, the action parameters, the confirmation state, and the final outcome.

When something goes wrong, the record should answer four questions: what happened, why the system allowed it, which untrusted input influenced the task, and whether a retry occurred.

These are not findings against Rindler. They are the checks I would run against any system that combines untrusted web content, authenticated sessions, scheduled execution, and actions that affect the outside world.

Getting an agent through the login is the capability. Proving that page content cannot borrow the user's authority is the security work.