Your AI employees act as their own users.
Each one holds its own identity in the systems you connect, so your access control, your approvals, and your audit records cover its work the way they cover everyone else’s. See what ran, what changed, and who decided.
Wallfacer has a SOC 2 Type I report for its own platform. See its scope and request a copy.
Talk to us about complianceNot on behalf of your people. As themselves.
The common approach gives an agent a human employee’s credentials and lets it act under their name. We do the opposite. Each AI employee holds its own identity, which is what makes auditability, access control, and compliance fall out of the platforms your team already runs.
Access control you already run.
An AI employee gets its own account in the systems you connect. The permissions, groups, and branch protections you set there govern its work, so there is nothing new to administer alongside them.
An audit answer with names in it.
Ask why a pull request shipped and the answer names the actors. Wallfacer Saul prepared the change, Wallfacer Auggie reviewed it, and a person approved the merge. Nobody has to reconstruct which human’s token was in use.
Compatible with modern security and compliance frameworks.
Because the work runs through your own gates and leaves records in your own systems, the evidence your frameworks ask for is the evidence you already collect.
What if a person directs an AI employee to do something inappropriate?
It is the first question a security team asks, and the answer is the record.
Everything an AI employee does is logged: every event that triggered the work, every conversation, every step and attempt, the computer it ran on, and the model it was using. Any decision an AI employee ever made can be traced back to what prompted it, so a forensic question has somewhere to go.
That changes what accountability looks like after an incident. Instead of telling a person they mishandled something an agent did under their name, your team can point at the procedure the AI employee followed and fix the step that was wrong.
They follow the checks you already have.
Pull request review, approvals, required checks: the safety and accountability gates your team already runs apply to an AI employee’s work. Nothing new lands on a person’s plate, because a code review is work a person already does.
- Assigned workAgent checks and review
The configured checks and review happen before the handoff.
Human decision
Approve, request changes, or stop.
Your existing release process
Continue through your team’s merge and release requirements.
A gate is not a dead stop.
When an AI employee needs something from a person, it asks in Slack, sends an email, or waits on the external service the work depends on. It does whatever moving the work forward requires, then picks the job back up where it left off.
GitHub branch protections and required checks remain controls you configure in your repository. Set AI employee permissions and playbook reviews to work with those requirements.
How the handbook worksFollow the work, including the corrections.
A requested change is part of the story. The task record connects recorded attempts and decisions so you can follow how the work moved forward.
An example task record: Implement the assigned GitHub issue
Illustrative sequence for a configured process.
Implementation assigned
Engineering AI employee · attempt 1
The AI employee prepares a change and requests review.
Review requests changes
Reviewing AI employee
The review records findings and returns the work for correction.
A corrected attempt
Engineering AI employee · attempt 2
The AI employee addresses the findings and brings the updated work back for review.
A person approves
Human reviewer
The work reaches the configured human decision.
The process used for the job
For a playbook run, the task retains the published process version it followed. Linked handbook pages have their own revision history.
People, AI employees, and attempts
Step records identify the performer, attempt, and recorded outcome. You can see where review sent work back and who made a decision.
A record you can inspect and export
Export the task record and compare it with pull requests, checks, and change history in your connected systems. Session links lead to the related conversation.
Give access for the job.
Choose the accounts and systems the AI employee needs. Credentials are used when preparing and running its environment; controls on storage and snapshots help manage that access.
Read about securityEncrypted values. Separate keys.
Stored secret values are encrypted. The keys used to unlock them are held in a separate key service.
The API keeps secret values write-only.
The customer API returns information about a stored secret, rather than returning its value.
Clean credentials out before saving.
The snapshot process removes per-identity credentials before saving the setup. If that cleanup fails, capture stops.
Bring your security team into the setup.
Review how the AI employee will work before connecting it to your systems. We can work through security questionnaires and the evidence your team needs to assess the setup.
Start with the questions that matter.
- Which systems can this AI employee access?
- Which actions need a person’s decision?
- What records will your team review and retain?
- Where will the code and credentials be used?
Work records are one part of an assessment. Your team evaluates them alongside your policies, connected systems, and applicable audit requirements.
Security detailsLet’s work through your requirements.
Bring the job, the systems it touches, and the decisions your team needs to keep. We’ll discuss access, review, and the records you need.
Talk about your controls