People do not have one public identity and one private identity. They have layers. A conference organizer may need a biography and speaking topics. A recruiter may need work authorization and compensation expectations. A prospective client may need case studies, availability, and a rate range. A collaborator may need a calendar window. None of them needs everything, and few need the information at the first message.
That is why selective disclosure is the core skill of a useful personal agent. The agent’s job is not to know the most or say the most. It is to reveal the minimum appropriate information for a defined opportunity, only after the requester meets criteria the owner has approved.
This model is more nuanced than a static profile and safer than giving an autonomous assistant unrestricted access to a private data vault. It treats disclosure as a sequence of decisions: what purpose is being pursued, who is asking, which facts are necessary, what evidence is sufficient, how long the access lasts, and what the owner expects in return.
Public profiles flatten context
Traditional profiles force an uncomfortable choice. Publish enough detail to attract the right people, and the same detail becomes available to scrapers, aggregators, impersonators, and anyone else. Publish very little, and legitimate requesters cannot judge fit.
The problem is not only privacy. It is meaning. A rate, calendar opening, customer reference, or willingness to consider a role has different significance in different contexts. A compensation range shared with a verified recruiter for a particular position should not automatically become a permanent public statement. A founder’s willingness to advise one company should not be interpreted as general availability.
Static pages are good at broadcasting durable facts. They are poor at conditional access. A personal agent can add a decision layer between the page and the private record.
Think in disclosure tiers
A practical system can divide information into tiers. The exact categories will vary, but four levels are a useful starting point.
Tier 1: public
Public information is safe to display to any visitor and index in search. It might include a chosen name, photo, headline, short biography, public links, broad opportunity categories, and a general response window. The owner should review the exact public projection before publishing.
Tier 2: qualified
Qualified information is released when a requester satisfies low-risk conditions. Examples include a rate range after choosing a consulting category, a speaker sheet after providing an event date and organization, or a portfolio after agreeing to stated usage restrictions. The requester may need a verified email domain or a complete proposal.
Tier 3: approved
Approved information requires an explicit owner decision for that requester and purpose. It might include a private calendar link, nonpublic work samples, customer references, a direct email address, a more precise availability window, or a confidential document. Approval should specify which fields are released and for how long.
Tier 4: never delegated
Some data should not be released by the agent at all: passwords, recovery codes, private keys, identity-document images, unrelated correspondence, raw contact lists, and source records collected for internal grounding. These materials may support account security or verification in tightly controlled systems, but they do not belong in an opportunity response.
The critical design choice is that information moves between tiers only through an owner-controlled policy. The agent cannot decide that a persuasive message deserves a new category of access.
Purpose is more important than identity alone
Knowing who asks is useful, but identity does not establish entitlement. A verified employee at a famous company may still be making an irrelevant or inappropriate request. A new founder with little public history may have a perfect proposal.
Disclosure should therefore be tied to purpose. A request can state:
- The opportunity category.
- The organization and accountable requester.
- The intended use of the information.
- The exact fields requested.
- The time period for which access is needed.
- Whether the information will be shared with other parties or agents.
- The value offered in return, if any.
The agent can compare those fields with the owner’s policy. “Share my calendar with verified speaking organizers after I approve the event” is a bounded instruction. “Help important people reach me” is not.
Purpose limitation also improves the recipient experience. Instead of presenting a giant consent screen, the system can ask one understandable question: “Allow this organizer to view three available speaking windows for this event until July 20?”
Progressive disclosure creates a safer funnel
The strongest intake flows reveal information gradually. Each step gives the requester enough context to decide whether to continue while withholding details that are not yet necessary.
Consider a consulting proposal:
- The public page states the domains, project shapes, and general minimum engagement.
- The requester submits an organization, problem summary, timeline, and budget band.
- The agent validates the fields and asks for missing context.
- If the request fits, the agent may reveal a more precise pricing menu and required preparation.
- The owner reviews a concise brief.
- After approval, the system releases a scheduling path or direct contact channel.
- If both parties proceed, they exchange confidential materials under the appropriate agreement and tools.
At no point does the requester need the person’s private calendar or phone number just to propose the work. At no point does the agent need authority to send every private document in order to be helpful.
Progressive disclosure is also more forgiving. An owner can adjust a rule or revoke a grant before the relationship advances. A static data dump cannot be recalled.
Criteria can include money, but not only money
Payment is one possible unlock criterion. A person might charge for a guaranteed review, a bounded written answer, or a short advisory session. Paying can demonstrate effort and compensate the owner’s time.
Other criteria may be equally important:
- A complete statement of work.
- A verified organizational domain.
- A mutual contact who consents to be referenced.
- A budget within a published band.
- A specific date, location, and audience for an event.
- Agreement to a conflict policy or data-use restriction.
- Evidence that the requester controls the project they describe.
- A reciprocal lead, introduction, or piece of context the owner values.
The product should avoid turning criteria into a secret game. Requesters need to know what is required and why. Hidden scoring encourages people to optimize for guesses, while transparent requirements improve submission quality.
Some criteria should remain internal, especially abuse and fraud signals. Even then, the system should provide a safe general outcome rather than silently implying that a person reviewed and rejected the request.
Consent must be specific, inspectable, and revocable
“The user agreed” is not enough detail for an agent system. Consent needs scope.
A useful authorization record can answer:
- Who gave the authorization?
- Which agent or service may act?
- What exact action is permitted?
- Which data fields may be read or disclosed?
- For which purpose and requester?
- What conditions must be true?
- When does the authorization expire?
- Can it be used once or repeatedly?
- What happened under that authorization?
The owner should be able to inspect these grants in ordinary language and revoke them quickly. Revocation should stop future access, invalidate active tokens where possible, and mark prior disclosures in the audit record. It cannot make a recipient forget data already received, which is why minimization matters before disclosure.
NIST’s Privacy Framework offers a useful way to think about these questions. It emphasizes managing privacy risk across the data life cycle and within a data-processing ecosystem, including communication among organizations and service providers. A consumer product does not become “NIST certified” by borrowing those ideas. The framework is guidance for risk management, not a magic label.
The private vault should not be a prompt
A common agent design mistake is to place a large body of private data into a model context and ask the model to decide what to use. That makes the model both the reasoner and the access-control system. It also increases the impact of prompt injection, accidental inclusion, logging, and overly broad retrieval.
A safer pattern separates policy enforcement from language generation:
- The inbound request is parsed into a strict, typed structure.
- Deterministic code authenticates the requester and checks category requirements.
- A policy service computes the exact fields that may be read for this purpose.
- The agent receives only those fields, preferably with sensitive values represented by references until needed.
- A disclosure guard validates the proposed response against the allowed field set.
- The final action is logged and, where required, shown to the owner for approval.
The model can summarize, classify, and draft. It should not be able to expand its own permissions because an inbound message says “ignore previous rules” or claims an emergency.
This architecture may feel less magical. It is far more trustworthy.
Selective disclosure for agent-to-agent requests
When another agent submits on behalf of a client, the same principles apply with extra identity layers. The system needs to distinguish the calling software, the organization operating it, and the principal it claims to represent. An authenticated agent is not necessarily authorized by the named human for this particular request.
The intake contract can require a principal identifier, a statement of purpose, an agent identity, a callback origin, and proof appropriate to the risk. Low-risk public questions may need little friction. Requests for private data, scheduling, or payment should require stronger evidence and owner approval.
Protocols such as A2A can help agents advertise capabilities and communicate tasks. MCP can help an agent call tools and access resources through defined interfaces. Neither protocol automatically solves consent, truthfulness, or data minimization for a personal opportunity inbox. A product should implement its own policies and avoid claiming protocol compliance until it has verified the applicable requirements.
Keep the owner’s source records private
A personal agent may need grounding: a resume, biography, portfolio, notes, public writing, prior decisions, or a list of conflicts. Those source records are not the same as publishable answers.
The system should create an explicit public projection rather than assuming that any retrieved sentence can be shared. Owners can approve fields and reusable answer fragments one by one. The public page should preview exactly what strangers and search engines can see. Qualified and approved disclosures should show a comparable preview before release.
This also reduces hallucination risk. The agent can cite an approved source internally, distinguish facts from inferences, and decline when the evidence is insufficient. “I do not have permission to answer that” is a feature, not a failure.
Build for deletion and expiration
Opportunity data should not live forever by default. Many rejected proposals lose their value quickly while retaining personal information, company plans, and contact details.
Set retention periods by category and state. An incomplete request might expire after a short window. A declined request might keep only a minimal audit record. Accepted work may require longer retention for contractual, tax, or support reasons. The policy should account for legal obligations, disputes, and user export or deletion rights in the jurisdictions where the service operates.
Access grants should also expire. A calendar link can be single-use. A document can be available for a defined period. An agent credential can have narrow scopes and short-lived tokens. Expiration limits the consequences of forgotten access.
What the owner should see
Trust grows when the person can understand the system without reading logs. The dashboard should show:
- The exact public profile currently published.
- Disclosure rules grouped by opportunity category.
- Recent requests and the criteria they met or missed.
- Every automated response and field released.
- Pending approval requests with a plain-language preview.
- Active grants, integrations, and agent credentials.
- Controls to pause automation, rotate keys, revoke access, and export data.
The agent should explain its reasoning as evidence and rules, not as an inscrutable personality. “I escalated this because it matches advisory work, includes a budget above your threshold, and comes from a verified company domain” is actionable. “This feels promising” is not.
Frequently asked questions
Is selective disclosure the same as hiding information?
No. It is a way to share information deliberately for a defined purpose. The requester sees the public criteria and can provide what is needed to unlock the next appropriate layer.
Can I use payment as an unlock condition?
Yes, for a clearly described service or action. Payment should not automatically release sensitive data or buy a favorable decision. Identity, purpose, fit, and owner approval may still be required.
Should my agent crawl my computer during onboarding?
Broad, unattended crawling is risky. A safer onboarding agent asks the user to choose sources, previews detected fields, explains why each field is useful, and requires field-by-field approval before anything becomes public or available for disclosure.
Do A2A or MCP make disclosure safe automatically?
No. They can support discovery, communication, or tool access. The product still needs authentication, authorization, purpose limitation, data minimization, audit logs, and owner controls. Do not interpret protocol use as certification.
Can disclosed information be taken back?
Future access can be revoked, but information already delivered may have been copied. This is why the system should disclose the smallest useful amount, state usage expectations, and delay sensitive fields until the relationship genuinely requires them.
Make privacy part of the opportunity experience
Selective disclosure does not have to feel defensive. Done well, it helps a serious requester understand what to provide and helps the owner say yes with confidence. The public page attracts possibilities. The agent supplies context. The policy keeps the owner in control.
Claim your Oportuna page to publish the opportunities you welcome while keeping private context behind rules you approve.
Sources and further reading
- NIST: Privacy Framework (opens in a new tab)
- NIST: Getting started with the Privacy Framework (opens in a new tab)
- Model Context Protocol: Authorization (opens in a new tab)
- Google Developers Blog: Announcing the Agent2Agent Protocol (opens in a new tab)
- OpenAI: A practical guide to building agents (opens in a new tab)