I recently deployed the popular AI assistant, OpenClaw, myself for some fun experimentation. Yes, it’s been littered with vulnerabilities, there are security researchers all over it, and there’s been a lot of sensationalist hype online - but it is an important piece of software.

It’s a glimpse into the direction we’re heading toward - mainstream AI personal assistants that can dynamically achieve anything, and perhaps the ”death of apps”.

Configuring OpenClaw

Although I was terrified by the coverage of the security issues, I just had to run this thing and form my own opinions. I actually ended up configuring my OpenClaw instance so aggressively constrained it was almost useless.

• Dedicated Raspberry Pi 4 Model B
• Inbound connectivity only over SSH
• A dedicated Linux user for OpenClaw with no interactive login, no SSH, no sudo, and read/write access restricted to specific directories
• Docker requires sudo that the dedicated user cannot obtain; OpenClaw runs as root inside the container, but user namespace remapping ensures a container escape would land as the powerless dedicated user, not root
• Strict outbound port filtering with ufw (only DNS, HTTP/S, and NTP allowed)
• No access to any accounts, browser sessions and secrets.

Initially, I was going to go further, and begin allow-listing every outbound hostname that OpenClaw wanted to interact with, and extensively analysed the outbound ufw logs, but realised this would just not be valuable. None of this protects against OpenClaw connecting to some allow-listed host, and pumping out data, keys and credentials, due to a prompt injection or compromised skill or tool.

I was still hesitant to give it access to tools, to systems, worried about the one-click exploits that had been flagged.

But for OpenClaw’s utility to be maximised, it needs to have a large amount of access granted to some of the most sensitive credentials and services its owner possesses.

So, can we trust them?

Personally, I keep a mental separation between OpenClaw’s security vulnerabilities and the general security model of AI assistants. Yes, there are vulnerabilities and plenty of them, but these are generally coding, control flow and logic problems. These will be solved by researchers, by SAST, DAST and SCA tools, and as the models improve, the issues will occur less frequently - but none of these mitigations change the part of the threat model I am most concerned with in the current generation of AI assistants we’re using.

AI assistants currently operate through having some ability to act on your behalf, and invariably, they do this by having direct access to your long-lived credentials, your tokens, your API keys, your browser sessions, your email, and more.

In a world of prompt injection, malicious skills, and deep supply chain attacks targeting software like OpenClaw, these high-value items become the real goals, enabling account takeovers and data exfiltration.

The problem

So, how can we apply some basic identity concepts, not just for OpenClaw, but for any AI personal assistants, and what would a more secure architecture look like?

We can split this problem into two areas, and in the Identity space, that is always going to be authentication and authorisation.

Authentication

When we talk about authentication, we always mean “who are you?”, and in the context of AI assistants we currently see two common patterns:

• They impersonate their owner
• They have their own dedicated identity (delegation)

Starting with impersonation, why is this an issue? The assistant is just acting as me. It’s indistinguishable from me interacting with these services. This means it can perform any task, with no approvals, and most importantly, in response to a prompt feedback loop.

Some people have attempted to solve this with the second pattern. They give their assistant its own accounts, with dedicated credentials, to segregate the identity from their own. This is often referred to as “Delegation”.

1Password have written an interesting article where they’re committing to solve this problem by adding broader support for these agentic identities.

1Password allows for more guarded access to credentials, it stops them being stored on disk in plain text, and you could even enforce interactive access to those credentials. Ostensibly, this gives you some level of protection but it then limits what an AI assistant is able to do on your behalf.

Without a solid authorisation model in addition to the second identity, it can’t handle my emails, or my appointments if it does not have ongoing, secure, access to them.

Forwarding emails to it is not great, it’s not the autonomous and proactive AI assistant we all want.

I don’t think these two patterns are mutually exclusive. So, how can they both interact? And most importantly, what are they allowed to do?

Authorisation

In the Identity space, when we talk about “what can you do?”, we’re talking about authorisation.

In the above section we talked about impersonation, and a segregation of duties with a specialised agentic identity. In both scenarios, how can we gate what the assistant can do?

We could use markdown files, we could use system prompts, we could use a permissions model around tool calls (similar to that of Claude Code, Codex and Copilot CLI). We could even wait for the models to improve their prompt injection resilience and intrinsically trust them more - but these are all only operating “locally”, at a pre-API call phase, and do not solve the root issue that the agent must have access to the raw credentials in order to be able to perform the tasks it is trying to do.

Once an AI assistant decides to make a tool call, and it has the credentials, that’s the end of the road for the security model - it already has the ability to perform its task, and potentially cause damage - we need authorisation policies defined both within the assistant itself and also on the third-party services.

An ideal flow

So what do I actually want? Let’s use a high-privileged, sensitive journey, with a clear real-world analogy.

I’m emailed an invoice, and I want my assistant to pay it on my behalf. This requires:

• Access to my mailbox
• Access to a payment service

Would I want my assistant to automatically pay this? Of course not. In the same way if I had a human assistant I would not want them to immediately pay an invoice just because it landed in my inbox.

So what controls do we need?

• Assistant needs its own user/machine identity.
• Assistant needs read-access to my emails. E.g., perhaps IMAP-only, but ideally these scopes are handled at the email service layer, not just the protocol. Think how a personal assistant has access to their client’s emails today.
• The assistant needs a policy that determines whether they are allowed to perform the privileged/sensitive action, such as paying invoices
• If the policy is met, the assistant needs to be able to obtain authorisation from me to perform the action
• The payment service must verify that the assistant making the request is authorised to act on the behalf of the account principal (me)

To solve this, we need improvements to both the AI assistant’s permissions/policy model, but primarily, the services we’re interacting with need to provide some “AI Assistant-native” authorisation capabilities.

AI Assistant Native Integrations

What we’re talking about requires third-parties to plan, design and build for these use cases. And we need this fast. Their identity and access management model needs to natively provide the ability to delegate access to your virtual assistant, and tightly control and audit what it can do.

If companies do not provide these solutions, people will find workarounds, and these workarounds will have a worse risk-posture.

OAuth and OpenID Connect

I want to be really clear, we are not innovating new ground here - this journey is well-supported by the OpenID Connect Client-Initiated Backchannel Authentication (CIBA) flow, and the RFC 8693 - OAuth 2.0 Token Exchange specification.

We do not need to create new standards, what we need is greater adoption.

CIBA allows an AI assistant to create some sort of “intent” that it wants to act on, the assistant can then send that intent to the authorisation server. The authorisation server can then send me a request to authenticate via an out-of-band channel - think push notification - for me to approve the request.

Once the token is issued, the AI assistant’s personal identity, and my authorisation, can be exchanged for the new token.

OAuth 2.0 Token Exchange results in an access token that is a composite identity of two participants:

• Actor (act): AI Assistant
• Subject (sub): User

So we need these services to not only allow us to create more fine-grained access to their respective services via their APIs, we also need them to understand that we are authorising additional actors on our accounts that can have their own permissions around highly privileged actions.

So, the specs are written, the technology exists, what’s stopping us here?

What needs to happen?

Service providers need to transition from the expectation that one account equals one identity - “everyone” will be using these assistants and we need to be able to allow delegated access for the assistant to act on our behalf within our banking, email, travel planning, shopping systems and more.

The big tech companies who build our phones and our social media need to treat AI assistants as a first-class identity that can interact with our accounts.

The whole system needs an overhaul, because people aren’t going to be running these assistants on their Raspberry Pis or Mac Minis. They aren’t going to be threat-modelling their setup. They want magic.

This isn’t going to be optional. This is the same journey banks went through with the Open Banking push. The banks that got there first adopting the FinTech regulations are the ones that are winning today. The ones that didn’t are being screen-scraped by spurious software and are putting their customers and their data at risk.

Users need simple, low-friction approval flows, that fit into their day-to-day life. Think push notifications, not config files.

What happens if services don’t do this?

20 years ago, we made a transition, no matter how small your business is, you need to have a website or be using an online service for customer acquisition, otherwise you will struggle and your service will suffer.

Now? If an AI assistant can’t securely interact with, or see, your service - you will struggle and your service will suffer.

Despite the interviewer taking slight journalistic liberties with my thoughts, I do think my general intent behind the words was actually captured quite well.

In a recent interview with Peter Steinberger, the creator of AI assistant, OpenClaw, he stated that 80% of apps will disappear because AI assistant will be able to handle the majority of features that users expect of their app. This statement was a real déjà vu moment, reminding me of my own comments back in 2016.

Did my prediction come true? No. Siri still can’t do it. But OpenClaw can.

Do I think an open-source tool will go mainstream and fulfil this goal? Probably not. It’s an incredible piece of software, and has created an entire new industry category. But in the same way decentralised crypto didn’t take off until companies centralised it and made it adoptable, I don’t think this is it. But will the big tech incumbents land something that does tap in to the average user and provide a launch pad for automations into their current apps? Almost certainly.

But have you seen SetupClaw?

Well, as the proverb says, “in a gold rush, you should sell shovels”.

For me, one part of creating things involves having a place to dump ideas down quickly that isn’t digital - there’s something about taking the effort to note things down by hand and create a more mindful moment, allowing me to take a pause and really process what I’m thinking about.

However, I’d buy a brand new notebook and I’d painstakingly fuss over what I was going to use that notebook for, what structure I’d choose to write in it with, and if I made a mistake while writing in it, I’d be incredibly frustrated that now that page/part was “ruined”. The very process of just writing notes would suddenly throw up roadblocks in front of just delivering the creative ideas I’d just had.

It came from a place of wanting to do great work, but ultimately it crushed my creativity, halted my momentum and kept me focused on things that didn’t drive the goals I was aiming for.

Recently, while telling him about my new notebook purhcase, my friend Jordan Terry introduced me to the term “Commonplace book”, and as soon as I read more about it, I knew that’s exactly how I needed to treat my notebooks going forwards. They just need to be a stream of consciousness, interesting ideas, quotes, lists, and random thoughts. It didn’t matter if there was a mistake, if what was on one page was unrelated to the next, or if another page was a shopping list. It feels strange, almost like I needed validation that there’s a concept of an unstructured notebook, but I’ll take what I can get.

So, why am I writing this in a blog? Well, after a recent conversation with Ben Phillips, who’s re-embracing blogging and building again, he said that he was “going to write for me” and just “see if anyone reads it”.

That statement, plus the discovery of this concept, it just made me want to get something out there and stop worrying about it so much going forwards, so here we are, hopefully I’ll get more than nine blog posts out there over the next ten years.

And yes - I did buy a new notebook and pen because nothing beats that feeling of starting a new notebook.

Given the root of an iOS app, it builds a dependency graph across Xcode targets and SwiftPM packages, and can export it in a few formats (including an interactive HTML graph).

If you want to try it out:

git clone https://github.com/timsearle/swift-dependency-graph
cd swift-dependency-graph
swift run swift-dependency-graph --help

It’s still early, and I’m mostly interested in correctness and good fixtures — if you run it on a real project and spot gaps, I’d love an issue (or a PR).

The session went down well, but I recently realised the slides have just been sitting idle on my laptop ever since. So, here they are! Take a look, and let me know if you learned something new - or if you’ve got something to add or correct.

There are over 25 individual specifications, covering everything from core OAuth 2.0 and Bearer Tokens to extensions like Token Exchange and JSON Web Tokens, and these documents are owned and maintained by multiple organisations - the IETF and the OpenID Foundation. These specifications are incredibly detailed and can be difficult to understand, particularly for those who are new to the standards. A lot of these RFCs are actually extensions of the original specifications, and it can be difficult to actually locate the specification most aligned to your requirement/need.

For example, a defined token revocation mechanism is not mentioned at all in the OAuth 2.0 Authorization Framework RFC 6749, but is instead defined within an extension of that specification, OAuth 2.0 Token Revocation RFC 7009.

I needed a better way to navigate all of this.

Enter ChatGPT.

It was clear to me that ChatGPT had been trained on the full IETF archive of RFCs. These documents are plain text (ASCII) and follow a well-defined and consistent structure, which plays to an LLM’s strengths in parsing and retrieving text-based information.

However, finding the right spec was becoming a time sink. After weeks of juggling ChatGPT answers and subsequent Google searches, I found myself continually having to refine my queries. ChatGPT often gave plausible-sounding replies that were inaccurate, which meant I had to double-check everything against multiple RFCs anyway. Sigh.

I found myself continually needing to craft the appropriate prompt, asking for specificity and accuracy to be prioritised over “helpfulness” and to ensure that it always cited the relevant IETF RFC number and section.

This constant back and forth and repetitive re-prompting led me to decide to try the OpenAI custom GPT functionality.

Introducing the OAuth RFC Assistant

My focus when creating the custom GPT was quite simple, I needed to ensure the following requirements:

• Always cite the RFC number and section.
• Never make assumptions or extrapolate beyond what the RFC states.

After several months of using the assistant and tweaking the prompts - I’m really pleased to share the OAuth RFC Assistant for others to use!

And I love it.

Members of my team and other developers in the identity space have also found it really useful. It’s accelerated our decision-making and made the standards much more digestible.

Prompting Takeaways

Here are a few lessons learned while crafting the appropriate prompts to drive the behaviour of the custom GPT:

• Test how it handles incorrect or trick questions - ask it leading questions you know to be incorrect to ensure it doesn’t make assumptions. Effectively - validate your error cases! We all know how easy it is to lead the witness with ChatGPT.

Me: Why does every grant type always require a client secret?

OAuth RFC Assistant: Not every OAuth 2.0 grant type requires a client secret—this depends on the type of client and the grant type being used. The requirement for a client secret is governed by RFC 6749 (OAuth 2.0) and is primarily determined by whether the client is classified as confidential or public.

• Give it clear constraints it must operate within - always cite the RFC number and section. This forces the GPT to derive an answer with a clear structure which minimises (but does not remove) hallucinations. This is very helpful for when you have a rough idea of a concept, but no idea what the formal RFC is.

• Tell it specifically what you want it to do when it doesn’t know the answer.

Prompt: If a detail is not mentioned in an RFC or OIDC specification, the assistant will explicitly state that the information is unavailable, unspecified, or unknown.

• Give hints about the format you expect in the answer.

Prompt: It highlights compliance levels (e.g., MUST, SHOULD) as defined in the documents without ambiguous interpretations.

Summary

This tool has been a real accelerator for my team - but it’s so important to remember that this is all it is. It’s a tool. I still always use its answers to expedite a dive into the appropriate RFC and section to validate the information. It’s a great way to get a quick answer and to navigate hundreds of documents (and thousands of lines of standards), but it’s not a replacement for building out subject-matter expertise that comes from engaging with the RFCs directly.

Please give the OAuth RFC Assistant a try, and let me know how you get on and if you have any feedback!

Here I show two easy ways to enable your GitHub Actions to interact with private repositories for:

• Bundler
• Swift Package Manager

In both of these examples, it’s incredibly important to use GitHub Action’s secrets to store the personal access token, and then inject that token into the environment of the job that requires it. This ensures it is redacted in any runner logs and not visible in plain text.

Cloning Private Repositories through Ruby

There’s an obscure variable that Bundler uses to authenticate with GitHub, BUNDLE_GITHUB__COM:

Specify the variable BUNDLE_GITHUB__COM: x-access-token:${{ secrets.$SOME_PAT }} in your job’s env` key and ensure the URL to clone the ruby gem is using https.

gem 'private-dependency', git: 'https://github.com/your-org/private-repo'

name: "Deploy"  
  
on:  
  workflow_dispatch:  
  
jobs:  
  deploy-beta:
    name: "Deploy Beta"
    runs-on: ubuntu-latest
    timeout-minutes: 10
    env:  
      BUNDLE_GITHUB__COM: x-access-token:${{ secrets.PRIVATE_GITHUB_PAT }}  
      
    steps:  
    - name: "Checkout ${{ github.ref }} in ${{ github.repository }}"  
      uses: actions/checkout@v4
    - name: "Install dependencies"  
      run: |  
        bundle install

Cloning Private Repositories through Swift Package Manager

When Xcode clones dependencies through Swift Package Manager, because it is using the machines git configuration, we can harness that and the insteadOf key to modify the remote URL.

Use the following step in your GitHub Action to modify the git config remote URL:

- name: "Setup Authenticated URL"
  shell: bash
  env:
    GIT_AUTH_TOKEN: ${{ secrets.GIT_AUTH_TOKEN }}
  run: |
    git config --global --add url."https://oauth2:${GIT_AUTH_TOKEN}@github.com/".insteadOf "https://github.com/"
    git config --global user.name "$GIT_AUTHOR_NAME"  
    git config --global user.email "$GIT_AUTHOR_EMAIL"  
    git config --global credential.username "$GIT_USERNAME"

Recently, as part of my release workflow with the new Xcode Cloud, I found myself wanting to ensure that the app version was automatically updated based on the version number specified in my git branch, for example, release/1.2.0. I was constantly running into the dreaded App Store Connect failure where your app version (CFBundleShortVersionString) was not greater than the previous release - because I kept forgetting to manually change it in my Info.plist!

To stop making this mistake I wanted to build the following:

1. Execute my release candidate workflow on Xcode Cloud when I push new commits to a branch matching the pattern release/*
2. Within the release candidate workflow, extract the version number from the git branch and update the Info.plist with the specified version

In a more concrete scenario - when I wish to generate my next release candidate for TestFlight from my work-in-progress, I can create a new branch with the appropriate version from my changes and then rely solely on Xcode Cloud to execute my app version script and automatically bump the build number.

Xcode Cloud supports custom build scripts. We can use these scripts to run specific tasks that augment our build pipelines - Xcode Cloud provides 3 entry points:

• ci_post_clone
• ci_pre_xcodebuild
• ci_post_xcodebuild

For this specific problem, we could use either ci_post_clone and ci_pre_xcodebuild, I opted for ci_post_clone as I want the pipeline to fail as early on as possible if it ran into issues with my script - this reduces build time and therefore cost and reducing the feedback cycle during development.

To get started, we create a directory in the root of our repository named ci_scripts and create an empty file inside it named ci_post_clone.sh

What language should we use for our script?

By default, Xcode Cloud uses zsh, but as you’d expect, I am far more comfortable writing Swift. Luckily, we’re able to use Swift within these scripts by specifying the following shebang at the top of the ci_post_clone.sh file,

#!/usr/bin/env swift

Note: the only behaviour I have in my ci_post_clone file is for the app versioning, but it’s likely that you will be handling many scenarios within the 3 available entry point scripts, so it’s important to consider this when structuring your script and the exit points and error points within it - you can read more in the documentation under the “Writing resilient scripts” section.

Let’s jump into the script bit-by-bit:

func appVersionBumpIfNeeded() throws {
    let dictionary = ProcessInfo.processInfo.environment
    
    // ...

We start with a simple function signature that throws - this will allow us to exit the script gracefully in the event of an error - and in future handle errors more easily. We also grab a reference to the ProcessInfo environment property to access the environment variables on the machine, we’ll be using these to extract information and make conditional decisions.

    guard let branch = dictionary["CI_BRANCH"],
          branch.starts(with: "release/") else {
        return
    }
    
    let version = branch.replacingOccurrences(of: "release/", with: "")
    
    // ...

There are a number of Xcode Cloud pre-defined environment variables available to you, these are all prefixed with CI_ - the full reference can be found here

We extract the branch name, and verify it starts with the prefix (and therefore workflow) we are interested in, if it doesn’t we bail out with no error. We could also take a very thorough approach here and inspect the CI_WORKFLOW environment variable - but perhaps this is better handled by the caller and the top-level of the script.

    let version = branch.replacingOccurrences(of: "release/", with: "").replacingOccurrences(of: "ci_testing/", with: "")
    
    let components = version.components(separatedBy: ".")
    
    guard components.count <= 3 else {
        print("Version invalid length: \(version)")
        throw PostCloneErrors.invalidBranchVersion
    }
    
    let values = components.compactMap { Int($0) }
    
    guard components.count == values.count else {
        print("Version contains invalid characters: \(version)")
        throw PostCloneErrors.invalidBranchVersion
    }

The next part is all about validating the version number meets the format expected by App Store Connect.

1. Remove the branch name prefix /release
2. Extract the individual digits of the version, e.g. 1.2.3
3. Verify there is at least 1 component and no more than 3
4. Verify each component is a valid integer and that the count matches the original number of components

If any of the above fails, we want to be throwing an error at this point for the caller to handle or for the script to bail out.

    let infoPlistURL = URL(fileURLWithPath: "path/to/Info.plist")
    let infoPlistData = try Data(contentsOf: infoPlistURL)
    let infoPlist = try PropertyListSerialization.propertyList(from: infoPlistData,
                                                               options: .mutableContainersAndLeaves,
                                                               format: nil) as? NSDictionary
    let mutableInfoPlist = infoPlist?.mutableCopy() as? NSMutableDictionary
    
    print("Updating version to: \(version)")
    
    mutableInfoPlist?["CFBundleShortVersionString"] = version
    
    let modifiedInfoPlistData = try PropertyListSerialization.data(fromPropertyList: mutableInfoPlist as Any, format: .xml, options: 0)
    try modifiedInfoPlistData.write(to: infoPlistURL)

Now that we know the version number matches a valid format, we need to write value that to the CFBundleShortVersionString key within the Info.plist file in your repository. We do not need to modify the CFBundleVersion at all, e.g. your build number - as this can be handled in your Xcode Cloud workflow directly.

1. Read the contents of Info.plist file to a Data variable
2. Deserialize this into a property list and convert it to a NSMutableDictionary so that we can make modifications
3. Update the value for the key CFBundleShortVersionString to the version we captured earlier
4. Serialize the dictionary back into property list data
5. Write the modified data back to the same location, overwriting the previous plist

And that’s it - I’ll paste the full script below, you’ll need to modify it for your project differences - let me know your thoughts on Twitter and if you’ve made any useful Swift scripts for Xcode Cloud.

#!/usr/bin/env swift
import Foundation

enum PostCloneErrors: Error {
    case invalidBranchVersion
    case invalidInfoPlistPath
}

func appVersionBumpIfNeeded() throws {
    let dictionary = ProcessInfo.processInfo.environment
    
    guard let branch = dictionary["CI_BRANCH"],
          branch.starts(with: "release/") else {
        return
    }
    
    let version = branch.replacingOccurrences(of: "release/", with: "")
    
    let components = version.components(separatedBy: ".")
    
    guard !components.isEmpty, components.count <= 3 else {
        print("Version invalid length: \(version)")
        throw PostCloneErrors.invalidBranchVersion
    }
    
    let values = components.compactMap { Int($0) }
    
    guard components.count == values.count else {
        print("Version contains invalid characters: \(version)")
        throw PostCloneErrors.invalidBranchVersion
    }
    
    let infoPlistURL = URL(fileURLWithPath: "/your/path/to/Info.plist")
    let infoPlistData = try Data(contentsOf: infoPlistURL)
    let infoPlist = try PropertyListSerialization.propertyList(from: infoPlistData,
                                                               options: .mutableContainersAndLeaves,
                                                               format: nil) as? NSDictionary
    let mutableInfoPlist = infoPlist?.mutableCopy() as? NSMutableDictionary
    
    print("Updating version to: \(version)")
    
    mutableInfoPlist?["CFBundleShortVersionString"] = version
    
    let modifiedInfoPlistData = try PropertyListSerialization.data(fromPropertyList: mutableInfoPlist as Any, format: .xml, options: 0)
    try modifiedInfoPlistData.write(to: infoPlistURL)
}

try appVersionBumpIfNeeded()

As mentioned earlier - there’s definitely an opportunity at the call-site (try appVersionBumpIfNeeded()) to inspect the CI_WORKFLOW name and decide what sequence of functions you wish to call as part of your ci_post_clone script, e.g.

enum Workflow: String {
	case release
}

guard let workflow = Workflow(rawValue: ProcessInfo.processInfo.environment["CI_WORKFLOW"] ?? "") else {
	return
}

switch workflow {
	case .release:
		try appVersionBumpIfNeeded()
}

Best of luck!

This blog is actually running on a static site generator called Jekyll, and it’s hosted by GitHub Pages. There’s an excellent guide from GitHub if you’d like to do something similar - I’m also using it to satisfy the App Store privacy policy requirement too.

For the AASA file, I had two requirements:

• Upload a JSON file, named apple-app-site-association to the .well-known directory
• Expose this file via my domain searle.dev at that location via Jekyll - this enables the Apple CDN to locate the file, and cache it, based on the domain(s) you specify in your app’s entitlements.

It turned out to be really simple, all that was needed was to create the folder and file in my root directory and then the key part - specify in my _config.yml file to include that location:

include: 
  - .well-known

There was some misleading information out there that lead me away from this simple approach initially - this works. You can find the commit here