AutoAdmin

AI that runs your back office—without running wild.

Comment

About the project

AutoAdmin started from a practical problem I could see clearly.

Websites may look simple from the outside, but many of them have heavy back-office systems that require several people to manage. There may be content editors, administrators, developers, security personnel and other specialised roles. Each person has different permissions, yet the work is often repetitive, difficult to audit and dependent on someone always being available.

I experienced this while working with the Graceway Fountain Ministries website. Its administration system includes full blog management and different levels of access. During testing, I discovered that a user who appeared to have a limited blogging role could still publish and unpublish posts through the browser. That finding changed how I thought about the project.

I realised that AutoAdmin should not only help manage websites. It should also help inspect them, identify imperfections, recommend corrections, carry out approved maintenance and retain evidence of what happened.

What inspired me

My main inspiration was the gap between what an organisation believes its administrative system allows and what the system actually permits.

Traditional automation often focuses on whether an action can be completed. I wanted AutoAdmin to ask a more important question:

Should this particular agent be allowed to perform this particular action, against this particular system, at this particular time?

That led to the central idea behind AutoAdmin:

Every action must earn its authority.

An agent should not receive unlimited access simply because it has been connected to a website. Its authority should be calculated from the task, its assigned capabilities, the target application, the available connector, the environment and any required human approval.

A simplified way of expressing this is:

[ A_{\text{effective}} = A_{\text{agent}} \cap A_{\text{task}} \cap A_{\text{connector}} \cap A_{\text{application}} \cap A_{\text{environment}} ]

If the requested action falls outside that intersection, AutoAdmin should reject it or pause for human review.

What I built

AutoAdmin is an open-source control plane for governed website administration, maintenance and correction.

It is designed to work with the systems an organisation may already have:

  • A public or authenticated API
  • A Git-enabled repository
  • A browser login to an administrative back office

These connection types can be used independently or combined. An API may provide reliable access to structured operations, Git may be used for reviewed code changes, and browser automation may cover administrative functions that do not yet have a suitable API.

The current MVP includes:

  • Application and connector onboarding
  • API, Git and browser connector types
  • Narrowly scoped, versioned agents
  • Capability discovery
  • Task planning and policy evaluation
  • Human approval gates for consequential operations
  • Approval-bound execution
  • Postcondition verification
  • An immutable execution timeline
  • Hashed evidence and retained artefacts
  • AI provider and model-profile configuration
  • AI-generated task proposals that still pass through the normal governance process
  • A searchable project knowledge base
  • A documentation assistant with verified source citations
  • An open-source landing page, Help centre and guided product experience

The Graceway Fountain Ministries website became the first real case study. It allowed me to test AutoAdmin against an actual administrative system rather than designing everything around ideal assumptions.

AutoAdmin is being built by Sapong Engineering. The initial goal is a useful self-hosted, open-source application. From there, I intend to develop it into a cloud-hosted SaaS product without abandoning the governance principles established in the MVP.

How I built it

I began with a contract-first vertical slice instead of generating a large amount of general scaffolding.

The first objective was to prove one complete path:

  1. Connect to a real application.
  2. Discover what the connected account can actually do.
  3. Compare those capabilities with the intended policy.
  4. Create a governed task.
  5. Require human approval where necessary.
  6. Execute through a confined connector.
  7. Verify the result independently.
  8. Retain evidence of every important decision and outcome.

The control plane is built in Go, with PostgreSQL providing durable storage for applications, connectors, agents, tasks, approvals, events, AI invocations and evidence. The web interface is built with SvelteKit. Browser workflows use reviewed and versioned Playwright adapters rather than allowing an AI model to operate a browser freely.

AI is treated as a bounded reasoning component, not as the final authority. It can interpret an operator’s intention, suggest a typed task and answer questions from the documentation, but it cannot silently invent capabilities or bypass the task policy.

For the documentation assistant, AutoAdmin indexes the project’s Markdown files into bounded sections. Relevant sections are retrieved for each question, and the model must cite only the exact sources it received. Invalid citations, extra authority fields and malformed responses are rejected and recorded as failed attempts.

I also used an Impeccable-led design process to shape and refine the interface across the landing page, console, Help experience and AI assistant. The aim was to make the product feel clear and deliberate while still showing the technical evidence behind each operation.

Challenges I faced

One of the greatest challenges was the difference between visible permissions and effective permissions.

A browser interface may hide an action while the backend still accepts it. A role name may sound restricted while the authenticated account possesses broader capabilities. AutoAdmin therefore cannot rely only on labels, menus or what is visible on a page. It must compare browser behaviour, backend policy, connector discovery and verified outcomes.

Browser automation also introduced practical challenges. Dialog overlays, changing selectors, authentication state and intercepted controls can cause unreliable execution. I addressed this by creating reviewed, versioned workflows with strict origin controls, exact execution grants and postcondition checks.

Another challenge was allowing AI to be genuinely useful without allowing it to become an uncontrolled administrator. A model can misunderstand a request, invent a capability or follow malicious instructions hidden inside user input or retrieved content. I responded by separating reasoning from authority. Model output is treated as an untrusted proposal until the control plane validates it.

Evidence retention created a further balance. The system needs enough information to prove what happened, but it must not expose passwords, API keys or private prompts. AutoAdmin stores secret references instead of raw secrets and records hashes and bounded metadata where retaining the original content would be unsafe.

Finally, the project required me to balance open-source simplicity with a future SaaS direction. The MVP needed to run locally and remain understandable to contributors while establishing boundaries that could later support hosted isolation, stronger authentication, managed secrets and organisational tenancy.

What I learned

This project taught me that safe automation is not mainly about making agents more powerful. It is about defining where their power ends.

I learned that human approval is meaningful only when it is bound to the exact task, parameters, target and plan being approved. A general approval that can be reused later is not a reliable safety control.

I also learned that verification must be separate from execution. A connector reporting success is not enough. The system needs to inspect the resulting state and confirm that the expected postconditions were satisfied.

Most importantly, I learned that real systems reveal problems which architectural diagrams cannot. The Graceway case study exposed an actual authorisation mismatch and helped turn AutoAdmin from a general administration idea into a more focused platform for governed management, maintenance and correction.

What comes next

The next stage is to expand the catalogue of safe, reviewed operations while keeping every action traceable and appropriately gated.

I plan to improve:

  • Connector templates for more platforms
  • Policy authoring and simulation
  • Secret-management integrations
  • Agent testing and capability review
  • Scheduled maintenance workflows
  • Approval notifications
  • Evidence export and compliance reporting
  • Multi-organisation isolation for the hosted version
  • A broader community-maintained connector ecosystem

My long-term aim is for AutoAdmin to help organisations operate complex digital systems with fewer repetitive manual steps, without asking them to sacrifice control, accountability or human judgement.

It is automation that can act—but must always be able to explain who authorised it, what it changed and how the result was verified.

Built With

Share this project:

Updates