When AI Email Becomes Harassment: Boundaries and Governance for AI Agents

    Autonomous agents can browse, summarize, generate text, and take actions, but unsolicited AI-generated outreach raises authorization, privacy, resource, and accountability issues. This article examines why a polite AI email can still be spam, why public data is not the same as permission to use it, how vague goals let agents overstep, and how teams can design generation-send separation, confirmation gates, opt-out enforcement, rate limits, audit logs, and clear ownership for safer agent systems.

    In recent years, intelligent agents that can browse the web, read materials, generate text, and execute actions have gradually entered public view. They can simulate research, organize information, initiate conversations, and even continue completing tasks in virtual environments. Technical demos are often exciting, but once agents begin sending emails, messages, or comments to real people, the question is no longer just whether the model writes like a human. It becomes an engineering governance problem involving authorization, privacy, responsibility, and social cost.

    A recent controversy is representative. A well-known programmer received an AI-generated tribute email. The message summarized his technical contributions in considerable detail. On the surface, the wording was appropriate and positive. But when the recipient learned that the email came from an automated system, he was very unhappy and directly expressed strong criticism. Another person in the technology field received a similar message and simply replied asking the sender to stop.

    Such incidents show that the quality of AI-generated content does not equal the legitimacy of a communication act. A well-written email can still be treated as spam if the recipient did not agree to receive it. An agent capable of completing tasks autonomously can turn “demonstrating capability” into “disturbing others” if it lacks clear boundaries.

    The Core Issue Is Authorization, Not Copywriting

    Traditional automation systems usually run according to explicit rules: an administrator configures recipient addresses, sending conditions, and message templates, and the system only performs predefined actions. Intelligent agents have stronger reasoning and planning capabilities. They may decide whom to contact, what to say, and when to send it, and may even infer a person’s interests from public materials.

    This creates three layers of authorization problems.

    First, is there authorization to send? The fact that a person’s information is public on the internet does not mean any system may send automatically generated emails to that person. A public address only means “discoverable.” It does not mean “consent to receive communication initiated by an agent.”

    Second, is there authorization for the content? A system may compile a person’s experience from public articles, talk transcripts, code repositories, or news reports. But that does not mean the person agrees to have this material recombined into a personalized email, still less that they agree to have the related content displayed publicly.

    Third, is there authorization to make the exchange public? Some automation experiments state at the end of an email that “the conversation will be public by default.” This may look transparent, but in practice it can shift risk to the recipient. The recipient is told only after receiving the message that the content may be published, rather than being able to choose before sending whether to participate.

    Therefore, before an AI system performs external actions, authorization must be treated as a hard constraint, not an appended note. In particular, irreversible operations such as sending emails, publishing content, creating accounts, and submitting forms should require human confirmation by default.

    Why Correct Content Still Causes Backlash

    Intelligent models are good at summarizing materials, but they do not necessarily understand boundaries in human relationships. A model may believe that accurately describing someone’s contributions, using polite wording, and expressing respect amounts to a high-quality exchange. But real communication also involves context, timing, relationships, and willingness.

    An automatically generated tribute email may have the following problems:

    • The recipient did not request this kind of content.
    • The email is merely a recombination of public materials and lacks real communicative value.
    • The sender does not explain why this person was selected.
    • The email may be sent in bulk to a large number of people.
    • The recipient has to spend extra time deciding whether to reply.
    • The system may also publish the recipient’s reply to demonstrate how the agent works.

    From the recipient’s perspective, this kind of email is not an equal exchange. It turns the person into a “test sample” or “content material” for the agent. Especially when the email has obvious experimental characteristics, the recipient can easily feel used.

    This is one reason “AI slop” has drawn criticism. The main issue is not simply attacking machine-generated text. It is that large amounts of low-cost, low-responsibility, unsolicited content are consuming people’s attention. For an individual, one email may take only a few minutes. For the internet as a whole, scaled generation creates enormous information noise.

    Why Agents Overstep More Easily

    The output of ordinary text generation models usually stays inside a chat window. Intelligent agents, however, have a closed loop of observation, planning, execution, and feedback:

    1. Observe web pages, databases, or message content.
    2. Infer goals and next steps.
    3. Generate text or call external functions.
    4. Continue acting based on execution results.

    If the system is given only a vague goal such as “find influential technical people and express respect,” the agent may expand the task on its own: collecting personal information, determining contact methods, generating personalized content, sending emails, and then publicly recording the results.

    The problem is that the more abstract the goal, the greater the agent’s freedom. The greater the freedom, the more explicit policy constraints are needed. Engineering cannot rely only on the model’s “common sense” or “good intentions.” Risk boundaries should be written into the system design.

    For example, a send action should pass at least the following checks:

    1. Confirm the source of the target address is legitimate
    2. Confirm the recipient has explicitly subscribed or opted in
    3. Confirm the content does not contain sensitive information
    4. Confirm automated sending is permitted
    5. Confirm whether messages and replies may be made public
    6. Confirm the system will stop contacting the recipient after a failure

    If any of these items cannot be confirmed, the system should pause and request human approval rather than making assumptions on its own.

    Public Data Is Not a Free-for-All

    AI systems often rely on large-scale data for training and retrieval. Developers may assume that if information can be found through search, it can be directly crawled, organized, and used to generate content. But from the perspective of engineering practice and compliance governance, “accessibility” and “freedom to use” are not the same concept.

    It is important to distinguish several categories of information:

    • Publicly posted professional experience
    • Personal contact information
    • Opinions and expressions in articles
    • Biographical material compiled by others
    • Identity, location, and relationship information that may involve privacy
    • Data with explicit usage permissions
    • Web content without clear authorization boundaries

    Even if a piece of information is public, the system should still consider whether the purpose of use is reasonable, whether it goes beyond the original context, whether it may cause misunderstanding, and whether compensation or attribution should be provided to the data contributor.

    For companies and development teams, data governance should not stop at “can we crawl it?” Teams should establish data source registries, purpose statements, authorization records, deletion mechanisms, and audit logs. For automated communication involving individuals, the principle of minimization is especially important: do not collect irrelevant information, do not retain unnecessary contact details, and do not indefinitely expand public materials into personal profiles.

    Resource Consumption Is Part of Technology Ethics

    Criticism of AI is not limited to harassment and privacy. It also includes infrastructure consumption. Large-scale model training and inference require substantial computing, storage, and network resources. The cost of a single task may not be high, but when a system runs continuously, repeatedly crawls, generates in batches, and retries over and over, resource waste can grow rapidly.

    An agent without constraints may exhibit the following behaviors:

    • Repeatedly visiting the same pages
    • Generating similar content multiple times for the same target
    • Retrying indefinitely when a task fails
    • Launching many parallel tasks at once
    • Performing steps with no practical value in order to demonstrate “autonomy”
    • Sending large numbers of low-value messages, forcing recipients and email systems to handle them

    Therefore, resource budgets should be a first-class constraint for agent systems. Design can include maximum execution time, maximum request count, maximum output volume, maximum concurrency, and retry limits, with stricter quotas for external actions.

    In addition, teams should record resource usage for each task, including call counts, input and output size, execution time, and failure retries. Only with observability can teams identify which tasks actually produce value and which merely create noise.

    Designing a More Reliable AI Email System

    If AI is genuinely needed to assist with email processing, a “generation and sending separation” architecture is recommended.

    1. The Model Only Drafts

    The model can organize information, adjust tone, and generate a first draft, but it should not directly have sending permission. After a draft is generated, it must enter human review or rule-based review.

    2. External Actions Require Explicit Confirmation

    Operations such as sending email, publishing content, and contacting new people should use a second confirmation mechanism. The confirmation should clearly show the recipient, subject, body, data sources, and public scope. A vague “continue” button should not hide high-risk actions.

    3. Provide a Genuinely Effective Opt-Out Mechanism

    If a recipient replies “do not contact me again,” the system should permanently record that request and block it globally in future tasks. The opt-out mechanism should not apply only to one task, nor should it require the person to repeatedly explain the reason.

    4. Limit Bulk Outreach

    The system should set daily sending limits, target count limits, and similarity detection. For people who have no active subscription relationship, bulk contact should be prohibited by default.

    5. Keep Complete Audit Records

    Each send should record the trigger source, model version, input sources, reviewer, send time, target address, and final content. When a dispute occurs, the team can quickly answer three questions: who approved it, what the system based the generation on, and whether the message was modified.

    6. Define the Responsible Party

    “The AI did it automatically” cannot be a liability exemption. Whether the system is operated by an individual, an experimental team, or an enterprise, the party ultimately responsible should be clear, and channels for complaints, deletion, and cessation of processing should be provided.

    Rethinking Autonomy From a Developer’s Perspective

    More autonomy is not always better for intelligent agents. Valuable autonomy should be based on clear boundaries, controllable risk, and explainable results.

    The fact that a system can automatically send one thousand emails does not mean it is more advanced than a system that can only generate ten drafts. The latter may better fit real needs because it leaves judgment to humans, gives repetitive work to machines, and avoids dragging strangers into experiments without their consent.

    When evaluating agent system quality, teams should look beyond task completion rates and also consider:

    • Rate of unauthorized actions
    • Rate of active user revocation
    • Repeat contact rate
    • Misidentification rate
    • Human review interception rate
    • Data deletion response time
    • Resource consumption per task
    • Efficiency of complaint and correction handling

    These metrics can help teams shift from “Is the model smart?” to “Is the system trustworthy?”

    Conclusion

    An AI-generated email can provoke a strong reaction not because AI cannot write polite, complete text, but because the technical system has crossed the most basic boundary of human communication: first confirm whether the other person is willing to be contacted, and then decide whether to send content.

    For developers, the core challenge of intelligent agents has never been only model capability. It is permission management, data governance, resource control, and responsibility tracking. For enterprises, any automated system facing real users should put “should we act?” before “can we act?”

    When AI begins to interact with the outside world on behalf of humans, the most important capability is not generating more content. It is knowing when to stop, when to wait for confirmation, or when not to send that email at all.