Orb disks and snapshots are encrypted at rest.
We don't have any options for faster deletion. In practice, we delete entries from the database as soon as you click the button, but cleaning up other resources like attachments and analytics take a bit longer (hours). 30 days is more of a "cover your ass" number.
We just shipped live video chat for your orbs and threads in @AmpCode.
Go to the new 'space' tab and you'll enter a shared space where you can chat with your team!
@CrasperJoome The controls - restricting access, signed commits, CI, ... - are the assurances you make.
Pull requests are a common control for change management. Talk to your auditor! A good one can give other options to meet the trust service criteria.
@ollymarkey > The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives.
🫠
@ejc3@thorstenball If an agent is reviewing my code, I'd rather do it in the dev loop rather than play ping pong with one over a PR.
The current crop of code review bots are pretty good! But they're designed around a workflow before agents existed.
@ejc3 I still use PRs occasionally, when they fit the workflow (don't tell @thorstenball).
We get the same benefits as automerge PRs through the Ship button in Amp, which runs the test suite before merging. But it keeps the agent in the loop to fix small issues and debug complex ones
Yeah it's a good question! CI might break more often than it would if we used PRs, but agents and the dev speedup it gives us are more than worth it.
I pulled the stats quickly and CI was green for 99.5% of the last 30d. If it breaks, it's fixed super quickly.
@rockatanescu had the same question - bit more discussion over here: https://t.co/AFwSsnEsxE
Two really sharp points.
Github checks that the author field matches the signing key's owner. So it's not perfect, but it ensures that commits can't be modified and the commit header is accurate.
In the past I would've agreed with you about blocking main being worse! But changes ship so fast that in practice it's actually... fine. Tooling helps too - the Ship button in Amp runs tests before pushing, so it's a bit closer to opening a PR and enabling automerge.
@jscheel What they want to satisfy is that changes are authorised. Saying "this group of people is authorised to make changes directly" is also a valid way of doing it.
@_kirodin_ Share the thread URL or a portal link (authenticated connection to your dev server running on the orb). If you want to collaborate, you can make the thread multiplayer.
When agents are writing the code, how you arrived at a diff is as important as the diff itself.
@jrowe6720 To your point about social proof, yeah this might not be the right fit for all teams. But importantly, SOC 2 doesn't say anything about requiring social proof, so you're free to choose whether it fits you or not.
@jrowe6720 It's an Amp thread - the transcript between you and the agent, showing the entire development process of your change - rather than a Slack thread.
@aiproductguy It's really nothing special: tests, security + infra checks, deploys. I think restricting merge access is a bigger lever.
PRs are the default control that auditors pick for change management, but not the only option - have a chat with them!
@ali_ilhami@rockatanescu The advantage I see is running tests in the agent keeps the loop open - if something breaks, it can automatically fix trivial issues (or ping you for something more serious).
You could absolutely set something similar up with PRs + monitoring, but this is the route we landed on.