The Prompt Control Problem
Over the last few weeks, I’ve been experimenting with Claude Desktop and custom-built MCPs (Model Context Protocols). One thing that immediately stood out: you can’t update the prompt. This means I have no control over how to guide the agent into doing work the way I work. This got me thinking about agent identity, and I wanted to share some quick takeaways—then I’d love to hear how you’re approaching this in your projects. When people do work, they operate within a Role, but how you execute that work is probably different than how someone else with the same title at your organization does their work. This personal approach is the unique value you bring. So here’s the question: Is there a mechanism for you to tell an agent how you do your work, in a world where prompts are becoming increasingly controlled by the chatbots you use and the MCP tools they run? I think the answer lies in rethinking agent identity altogether.The Missing Layer: From Prompt Control to Agent Identity
The MCP prompt control problem reveals a deeper architectural challenge. Current AI systems conflate what an agent can do (capabilities) with how it should behave (identity). Traditional Role-Based Access Control (RBAC) gives us binary permissions, but what we really need is a way to encode not just permissions, but preferences, workflows, and context-aware decision making. This is where a more sophisticated model of agent identity becomes crucial. Instead of losing control over how an agent works when using tools like Claude Desktop with MCPs, we need a framework that preserves and expresses your unique working style across different AI interactions.Why We Need More Than RBAC
In today’s AI-driven world, agents perform critical tasks autonomously. Beyond asking whether an agent can perform an action, we must define when, why, and under what context it should—and should not—act. Traditional Role-Based Access Control (RBAC) employs static, binary scopes (e.g.,gmail.read, slack.post) that quickly become unwieldy across multiple roles and environments.
Scenario: Rahul Parundekar uses a single inbox (rahul@aihero.studio) to:A blanket
- Oversee investor communications as CEO
- Address on-call alerts as DevOps Lead
- Manage RSVPs as Community Organizer
- Analyze portfolio performance as Investor
gmail.readpermission would let a DevOps agent inspect payroll emails or allow an Investor bot to archive deployment alerts—outcomes that violate principle of least privilege.
A Contextual Ontology: Roles, Profiles, Agents
To resolve these limitations, we propose three foundational concepts:- Role Defines a set of context-aware, semantic permission clauses within an Organization.
- Profile Binds a Person to a specific Role within an Organization.
- Agent A software principal that assumes a Profile, acting on behalf of the associated Person.
1. Role
ARole lives inside an organization and comprises:
-
organization: Identifier (e.g.,AI Hero Inc.ororg-12345) -
title: Role name (e.g.,CEO,DevOps) -
capabilities: A list of high-level policy clauses (RFC‑style):MUST: ObligationsSHOULD: RecommendationsMUST NOT: ProhibitionsMAYorCAN: Optional capabilities
2. Profile
AProfile associates a Person with a Role. Profiles contain no additional instructions and represent the static binding between a person and a role. Agents may assume any existing profile.
Persona
APersona extends a Profile by including task-specific instructions. Personas encapsulate both the role and the operational guidance an agent should follow.
- Newsletter Manager Persona
- Board Interaction Persona
- Team Morale Persona
ProfileConstraint
AProfileConstraint defines the subset of profiles or personas an agent is authorized to assume.
3. Agent
AnAgent is a programmatic identity that selects one Profile before acting:
Example: Fine-Grained Gmail Permissions
Model Rahul’s CEO profile with contextual Gmail access:Advantages
- Least Privilege by Context: Agents operate only within their profile’s scope and temporal constraints.
- Expressive Policy DSL: Free-text, RFC-like clauses capture real-world nuances.
- Unified Model: No separate contract layer; Roles encapsulate both scope and policy.