Tag: artificial-intelligence

Starting a career in Confidential Computing

Whether your interests lie in research, design, engineering or operations, there will be opportunities to find rewarding careers in Confidential Computing.

An IDC report published at the end of Q4 2025, revealed that nearly 75% of respondents saw “Lack of skilled personnel” as a hurdle to adopting Confidential Computing.  I was recently speaking at a conference on the subject of security – including, of course, Confidential Computing – and was answering questions in the hallway afterwards when someone asked me, “how would you suggest I start a career in Confidential Computing?”  The person asking was an engineer and had a good understanding of the basics, having spent some time a year or so ago trying out the technology, but now wanted advice on how to forge a career in the area.  As the Executive Director of the Confidential Computing Consortium, this felt like a topic on which I should have an opinion: I thought it might be interesting and useful to provide my thoughts here in an attempt to help fill the perceived gap in the expertise market.

There are, I think, four broad areas – though I initially replied with three – for someone looking to pursue a technical career in Confidential Computing.  There’s definitely overlap, and also opportunities for non-technical paths, but I’m going to concentrate on engineering-related, or at least heavily technical roles:

  1. Research
  2. Infrastructure
  3. CC-dedicated
  4. Generalist

Research

In Q2 of 2026, the CCC published a call for research proposals to receive funding from a grant fund. We expected a handful and received over 35 applications and several after the cut-off date. This signals that research in Confidential Computing topics is alive and well within academia. Some of these will be around low-level hardware and firmware, others much higher up the stack in, for instance, attestation and endorsement protocols. There are also opportunities for research outside academia in some of the key companies in this space who are building the infrastructure for Confidential Computing, but also for independent researchers interested in working on specific projects or vulnerabilities. As Confidential Computing matures and more use cases emerge, we can expect research opportunities to continue to grow.

Infrastructure

The industry needs to build out the infrastructure to allow Confidential Computing to become fully commoditised – and then to create offerings that provide ways for providers to differentiate themselves.  This area is particularly broad, as it encompasses everything from silicon design to cloud computing services such as key management services and all the way to Attestation Verification Services (AVS).  It also includes, as the Research area does not, roles within operations which can expect to look different to existing operations roles as monitoring, debugging and management techniques adapt to Confidential Computing.  Many of these jobs will be in silicon vendors, OEMS, hyperscalers and cloud service providers, but there are also likely to be existing enterprises and new start-ups who will be finding a niche in the Confidential Computing services market and need talented and expert engineering resources to succeed.

CC-dedicated

This area maybe overlaps a little with the enterprises and start-ups looking for a niche in the Confidential Computing ecosystem, but, more specifically refers to applications and services that make use of Confidential Computing in new ways, or adapt existing products to make the most of Confidential Computing, enabling new offerings to be provided to the market.  There are already many start-ups who have identified market opportunities opened up by Confidential Computing in pretty much any sector you can imagine, leveraging the capabilities of TEEs and the enabling power of attestation to do new things or existing things more securely.  Such organisations will need engineers ready to work closely with product and service teams to build applications and frameworks that require deep understanding of Confidential Computing and how it works in a specific engineering context.

Generalist

Where engineers within a CC-dedicated organisation need to work in a specific engineering context, the generalist area is one suited to those who want to help spread Confidential Computing more widely.  This sort of role will see people working either as an internal or independent consultant or as a part of a security team looking to help organisations extend their use of Confidential Computing to existing or new applications and services.  They may specialise in Confidential Computing technologies and how to apply them, or have them as part of their larger engineering, design or architectural armoury in the same way that experts in the use and application of cryptography might advise an engineering team on how to build security primitives into their component or how on how to apply cryptographic protocols to a larger system.  In either case, technologists following this path are likely to encounter a variety of different applications of Confidential Computing and will need to be able to apply the appropriate primitives, tools and techniques to the job in hand.

Conclusion

As Confidential Computing becomes more established as a “must-have” technology and the ecosystem continues to expand, we will continue to build a talent base of expert engineers. Whether your interests lie in research, design, engineering or operations, there will be opportunities to find rewarding careers in Confidential Computing.

Who’s saying “hello”? – agency, intent and AI

Who is saying “hello world?”: you, or the computer?

I don’t yet have one of those Google or Amazon talking speaker thingies in my house or office.  A large part of this is that I’m just not happy about the security side: I know that the respective companies swear that they’re only “listening” when you say the device’s trigger word, but even if that’s the case, I like to pretend[1] that I have at least some semblance of privacy in my life.  Another reason, however, is that I’m not sure that I like what happens to people when they pretend that there’s a person listening to them, but it’s really just a machine.

It’s not just Alexa and the OK, Google persona, however.  When I connect to an automated phone-answering service, I worry when I hear “I’ll direct your call” from a non-human.  Who is “I”?  “We’ll direct your call” is better – “we” could be the organisation with whom I’m interacting.  But “I”?  “I” is the pronoun that people use.  When I hear “I”, I’m expecting sentience: if it’s a machine I’m expecting AI – preferably fully Turing-compliant.

There’s a more important point here, though.  I’m entirely aware that there’s no sentience behind that “I”[2], but there’s an important issue about agency that we should unpack.

What, then, is “agency”?  I’m talking about the ability of an entity to act on its or another’s behalf, and I touched on this this in a previous post, “Wow: autonomous agents!“.  When somebody writes some code, what they’re doing is giving ability to the system that will run that code to do something – that’s the first part.  But the agency doesn’t really occur, I’d say, until that code is run/instantiated/executed.  At this point, I would argue, the software instance has agency.

But whose agency, exactly?  For whom is this software acting?

Here are some answers.  I honestly don’t think that any of them is right.

  1. the person who owns the hardware (you own the Alexa hardware, right?  You paid Amazon for it…  Or what about running applications on the cloud?).
  2. the person who started the software (you turned on the Alexa hardware, which started the software…  And don’t forget software which is automatically executed in response to triggers or on a time schedule.)
  3. the person who gave the software the instructions (what do you mean, “gave it the instructions”?  Wrote its config file?  Spoke to it?  Set up initial settings?  Typed in commands?  And even if you gave it instructions, do you think that your OK Google hardware is implementing your wishes, or Google’s?  For whom is it actually acting?  And what side effects (like recording your search history and deciding what to suggest in your feed) are you happy to believe are “yours”?)
  4. the person who installed the software (your phone comes with all sorts of software installed, but surely you are the one who imbues it with agency?  If not, whom are you blaming: Google (for the Android apps) or Samsung (which actually put them on the phone)?)
  5. the person who wrote the software (I think we’ve already dealt with this, but even then, is it a single person, or an organisation?  What about open source software, which is typically written, compiled and documented by many different people?  Ascribing “ownership” or “authorship” is a distinctly tricky (and intentionally tricky) issue when you discuss open source)

Another way to think of this problem is to ask: when you write and execute a program, who is saying “hello world?”: you, or the computer?

There are some really interesting questions that come out of this.  Here are a couple that come to mind, which seem to me to be closely connected.

  • In the film Wargames[3], is the automatic dialling that Matthew Broderick’s character’s computer carries out an act with agency?  Or is it when it connects to another machine?  Or when it records the details of that machine?  I don’t think anyone would argue that the computer is acting with agency once David Lightman actually gets it to complete a connection and interact with it, but what about before?
  • Google used to run automated programs against messages received as part of the Gmail service looking for information and phrases which it could use to serve ads.  They were absolutely adamant that they, Google, weren’t doing the reading: it was just a computer program.  I’m not sure how clear or safe a distinction that is.

Why does this all matter?  Well, one of the more pressing reasons is because of self-driving cars.  Whose fault is it when one goes wrong and injures or kills someone?  What about autonomous defence systems?

And here’s the question that really interests – and vexes – me: is this different when the program which is executing can learn.  I don’t even mean strong AI: just that it can change what it does based on the behaviour it “sees”, “hears” or otherwise senses.  It feels to me that there’s a substantive difference between:

a) actions carried out at the explicit (asynchronous) request of a human operator, or according to sets of rules coded into a program

AND

b) actions carried out in response to rules that have been formed by the operation of the program itself.  There is what I’d called synchronous intent within the program.

You can argue that b) has pretty much always been around, in basic forms, but it seems to me to be different when programs are being created with the expectation that humans will not necessarily be able to decode the rules, and where the intent of the human designers is to allow rulesets to be created in this way.

There is some discussion about at the moment as to how and/or whether rulesets generated by open source projects should be shared.  I think the general feeling is that there’s no requirement for them to be – in the same way that material I write using an open source text editor shouldn’t automatically be considered open source – but open data is valuable, and finding ways to share it is a good idea, IMHO.

In Wargames, that is the key difference between the system as originally planned, and what it ends up doing: Joshua has synchronous intent.

I really don’t think this is all bad: we need these systems, and they’re going to improve our lives significantly.  But I do feel that it’s important that you and I start thinking hard about what is acting for whom, and how.

Now, if you wouldn’t mind opening the Pod bay doors, HAL…[5]

1. and yes, I know it’s a pretense.

2. yet…

3. go on – re-watch it: you know you want to[4].

4. and if you’ve never watched it, then stop reading this article and go and watch it NOW.

5. I think you know the problem just as well as I do, Dave.