This is a guest post by Peadar Coyle, the Co-Founder and CTO of Audiostack. Audiostack is the leading Generative AI infrastructure platform for audio creation that is used for advertising, video voice over, podcasting and dynamic audio.
The TL;DR from Peadar
- Permissions are critical for Generative AI companies to safeguard intellectual property of their customers and other design contributors
- As your company grows, evolving your architecture means outsourcing some of your infrastructure
- Your authorization service should be flexible and make it easier for your team to adjust rules or roles as your application evolves
- Auditing, testing and debugging is key to managing authorization and ensuring your models do the job
- Authorization modeling, the rules of who can do what, should be intentional, but as mentioned, they can evolve over time and there are paradigms that can help!
At Audiostack, we’re building an Enterprise generative AI platform, and we handle a lot of intellectual property like sound, content, and voice. All of these are important to safeguard, but voice in particular is important to protect because it is personally identifiable. Permissions and the auditing that goes along with them are very important for us to ensure the trust and safety of our customers.
Sins of the Past
We had originally built our own organization management system, and it was running into scalability issues. We had a developer who built and owned the system, but then he left for another opportunity. We were left with his legacy. It wasn’t documented and as new issues came up, we didn’t have the knowledge or capacity to handle them. We realized we needed to rebuild.
We could have built this type of service ourselves, but in mapping out our new authorization solution, we decided to outsource what we could, a decision that was quite welcome. At the time, we had a ton of new customers signing up, so evolving our permissions and up-leveling anything related to Privacy and GDPR compliance was important. Additionally we were in the middle of a larger app re-write, so we had a lot of buy-in collectively that this was a good time for us to get rid of the “sins of the past.”
I spent some time looking at Zanzibar and a few other papers on this, but as we were searching, Oso was recommended to us in a Slack community. We loved Polar – the declarative configuration language that Oso builds and maintains – because it was very well thought-out and systematic. The structure of Polar allowed us to more easily express complicated relationships and scenarios. Additionally, Polar allowed us to take the authorization out of our application. We were able to move that logic into a separate file, which makes it easier to audit and watch for changes. Finally, I thought the Polar documentation was very clear and helpful.
We had a number of stakeholders in our customer base that we needed to think of — our core customers, their internal collaborators, and agency partners — so we had to understand how we would design it all. We had to determine how to fit our user’s relationship with the product into the RBAC/ REBAC paradigm. Polar is fairly opinionated on how to model specific relationships, which made the process easier on us.
Flexibility and Centralization
One major consideration was flexibility. There’s a lot of management involved in roles and permissions, and in a homegrown system, the complexity of an authorization service adds to your daily toil.
One of the most humbling parts of building software is how your customer’s feedback helps your product evolve. For us, a lot of that evolution has been around organization roles. Over the course of our iterations, we needed to deprecate some roles. In our legacy system, whenever we needed to adjust or depreciate a role, we had to edit it in multiple places — we had to update 10 services in one deployment, at the same time to make this happen. Afterward, there was no way to audit if the change was successful or not. This challenge drove us to an approach that let us manage permissions centrally.
This scenario is fairly easy in Oso since there is a central place to store the roles. For each update, you can just edit it all in one place.
Implementing Oso was relatively easy. The harder part was designing and modeling the roles, which was a learning curve where the Oso team was able to help. As we’ve matured, we’ve recognized some of those rules need to change, and instead of a time-consuming update, we just deprecate them in one place. And that's okay. That's part of the flexibility.
Testing and Debugging
Auditing, testing, and debugging would have been hard to implement in our legacy system. If we had built this alongside the authorization service, then we would have to maintain an entire standalone product. Often what happens in a startup is that there is a “hacky” version of something, which is relatively easy to build — and sometimes fun — but then when you see the use cases evolve alongside the rest of the product – like adding adding logging, auditing, and monitoring – they become more work to manage yourself.
With Oso, testing and debugging is baked into the service. We’re able to test policies to see which voices can be accessed by which users. This allows us to ensure our authorization models are working correctly. There’s also a new feature called “Explain,” which shows us why a policy test might have failed.
The Value
Some things we’ve been able to do now that we have Oso:
Our team has outsourced an entire service we used to maintain ourselves
We’ve enabled our support teams to self-serve on behalf of our customers. For example they can now:
- Invite a user to a Beta program without involving the engineers
- Give users access to specific voices and sounds as needed
- Allocate permissions to users, i.e., modify what they can and can’t see
For our agency customers, it gives them more control over who has access to what services, sounds and voices
How you can AuthZ
My advice for folks building an authorization service or building on top of one: start simple and add complexity over time. Figure out the MVP and then move from there. It takes time to design these systems, as well as your specific roles and permissions, and moving up in complexity allows you to do that more intentionally and accommodate a steep learning curve.
Suggested Guides
- Model Common Authorization Use Cases (Oso)
- Authorization Rules are always harder than you think (Oso)
